Consider name generation being configurable. about gopher-luar HOT 5 CLOSED

You would want to store such information in the Lua state registry. See getMTCache in cache.go for an example of how we currently use the registry.

from gopher-luar.

@bontibon I see you already assigned this to you, but I went ahead and put what I was thinking into code and made a PR. Would love a code review when you have time. Thanks!

from gopher-luar.

Thanks for your thoughts, @bbuck.

I agree that the enforced dual naming for (at least) methods is not great. Struct fields I'm not as concerned about, as they can be explicitly set with the "luar" tag.

Your proposed solution and PR with the luar.Configure function cannot be added, as it modifies global state. The solution needs to operate on types in a specific *lua.LState.

A possibility I see is adding a helper to luar.MT that removes (or prevents) a specific set of methods.

from gopher-luar.

Where would a good place be to store this information on an LState? I've toyed with a similar feature in my current project for passing around values tied directly to an LState but I'm not sure how best to store meta information. I started using globals like _SOME_GLOBAL_NAME on the state but then, for my use case, chose to wrap stats with a data container so that values can't be modified from within scripts run.

Long story short, I'm not super familiar with the internals of Lua (yet) but I'm trying to learn. Where do you think might be the best place to store information like this? I'm totally willing to make the change in my PR.

from gopher-luar.

Thanks for doing this, much more compact than the new concept that I had.

from gopher-luar.