Extend indirect key access and mutation via tbl_get and add tbl_set about neovim

[clason]

it would be also useful

What for? What would it allow you to do that you can't do now?

[lewis6991]

I don't think we need this in core. Obviously feel free to provide one for yourself.

[justinmk]

@asmodeus812 you might want to try #24597 , which provides this interface:

local t = { a = { b = { c = 'foo' } }}
local nested_item = vim.get(t).a.b.c()
-- Assignment also works:
vim.get(t).a.b.c = 'bar'

The one quirk is that .c() is required on the final access when doing a "get".

I don't think we need this in core.

I don't really agree. Traversing data is very common and if we could improve it, we should. Though vim.tbl_set is not a great way to do it. If the compromises in #24597 could be fixed somehow, I don't see why we wouldn't include it.

[lewis6991]

I haven't seen many pieces of code that are in desperate need of this. If this was that important it would be obvious.

Are there any plugins you know of where this kind of pattern is typical? Or any examples of this in other programming languages where it is clearly valuable?

Personally I type and normalise all of my data structures and I find this kind of dynamic style quite an anti-pattern.

Even vim.tbl_get is seldom used which suggests to me it probably shouldn't have been added to begin with.

[justinmk]

Are there any plugins you know of where this kind of pattern is typical?

It becomes obvious in any language that supports optional chaining. This kind of access pattern is common, and avoids having to check each child individually:

a?.b?.c

If you are asking about "set" specifically: that is the un-problematic part of #24597 so it needs much less justification. The use-case is similar, though not as common.

[lewis6991]

Of course JavaScript of all languages has something like that.

a?.b?.c

How about

((a or {}).b or {}).c

Not quite as pretty, but doesn't require anything special, is completely portable and can be well understood by LuaLS.

I don't think there's enough code in the wild to justify adding convenience functions to sugar this.

[justinmk]

How about

((a or {}).b or {}).c

I'm aware of that :)

Not quite as pretty, but doesn't require anything special, is completely portable and can be well understood by LuaLS.

There's really nothing special about #24597 (if it were matured / fully-formed). I don't see LuaLS as something that should block useful data traversal.

I don't think there's enough code in the wild

The "ad hoc" use case is very important. REPL-like usage may not end up in production code, but is at least as important.

[lewis6991]

#24597 is already using quite a lot of tools from the from the Lua toolbox. I'd be pleasantly surprised if that can be improved at all.

I spent many hours/days trying to solve a similar problem (multi key set) with vim options, and came to the conclusion that it's not possible and we just need to accept the constraints given to us by Lua. As we've seen with vim.iter, plain Lua is often more readable and understandable than some elaborate API.

And in general, and I don't say this enough, we need to stop inventing shit we "think" is useful and let the community do that for us who are dealing with the problems and all the nuances. Our role works best to promote and refine existing solutions. E.g. vim.loader, vim.system, built-in commenting, and hopefully some async interface in the future. If we develop solutions to problems from internal work then that's fine too, but there has to be non-hypothetical problems.

The "ad hoc" use case is very important. REPL-like usage may not end up in production code, but is at least as important.

Not the most persuasive point, but maybe I just don't use the REPL enough (other than debug)?

[justinmk]

As we've seen with vim.iter, plain Lua is often more readable and understandable than some elaborate API.

And in general, and I don't say this enough, we need to stop inventing shit we "think" is useful and let the community do that

I 100% agree, of course. #24597 was driven by my own use-case and experience, not hypothetical. It seems clear to me that the main sticking point is about type safety, in this case.