Re: [Proposal] _GETNAME upvalue

["Soni \"They/Them\" L." <fakedme@...>]

On 2021-06-22 6:18 p.m., Marcus Mason wrote:
> I'm not serious about this being a good solution.
> What I wanted to highlight was that __index being able to ask the
> calling environment to provide keys is effectively what you want.
> The other stipulations about t.key vs t[key] seem strange and would
> break the current t.key invariants.
>
> Do you think `nil.key` being an error depending on the upvalues of the
> current chunk is a good idea? If was tied to a metatable at least then
> it would be somewhat predictable.
>
> Why is wrapping an object in a proxy to add more functionality a bad
> pattern compared to this?
>
> How does this work with free variables?

It's just defining the dot operator in terms of upvalues. Or deprecating
the old dot operator and making a new one defined in terms of upvalues.

Just a different way to think about things, is all.

Also, nil.key doesn't compile. :p

>
>
> On Tue, Jun 22, 2021 at 2:27 AM Soni "They/Them" L. <fakedme@gmail.com
> <mailto:fakedme@gmail.com>> wrote:
>
>
>
>     On 2021-06-21 8:45 a.m., Marcus Mason wrote:
>     > You can already produce this effect in lua. This is not a complete
>     > recreation because real extension methods (a la C#) should override
>     > methods no matter where they come from. Lua doesn't have methods
>     so it
>     > doesn't make sense.
>     >
>     > https://gist.github.com/Mehgugs/385557d1c88860b46239a796907d8bd8
>     <https://gist.github.com/Mehgugs/385557d1c88860b46239a796907d8bd8>
>     >
>     <https://gist.github.com/Mehgugs/385557d1c88860b46239a796907d8bd8
>     <https://gist.github.com/Mehgugs/385557d1c88860b46239a796907d8bd8>>
>     >
>     > Personally this seems a bit pointless because you can just use
>     __index
>     > on a proxy table to achieve this effect since there's no methods and
>     > symbol resolution in lua.
>
>     _GETNAME is much cleaner: It can be exposed to a sandbox, works
>     with all
>     objects (and types), works with debug symbols stripped, supports
>     dynamic
>     dispatch, doesn't involve wrapping/unwrapping, actually handles
>     proxying
>     (where other modules go through your module to access stuff, i.e.
>     t[key]
>     syntax, which should not be overridden), among other things.
>
>     There's no way you can be serious about this "solution".
>
>     >
>     > On Mon, Jun 21, 2021 at 12:39 PM Notabored guy
>     <notaboredguy@gmail.com <mailto:notaboredguy@gmail.com>
>     > <mailto:notaboredguy@gmail.com <mailto:notaboredguy@gmail.com>>>
>     wrote:
>     >
>     >     I personally don't see the use of it.
>     >
>     >     On Mon, Jun 21, 2021, 12:48 Soni "They/Them" L.
>     <fakedme@gmail.com <mailto:fakedme@gmail.com>
>     >     <mailto:fakedme@gmail.com <mailto:fakedme@gmail.com>>> wrote:
>     >
>     >
>     >
>     >         On 2021-06-21 4:33 a.m., Egor Skriptunoff wrote:
>     >         > Why might we want to redefine methods of an object locally
>     >         (inside the
>     >         > current module) instead of globally (everywhere the object
>     >         appears)?
>     >         > Please provide real-life examples
>     >         >
>     >
>     >         local _GETNAME = function(o, k)
>     >           if type(o) == "table" and k == "insert" then return
>     >         table.insert end
>     >           return o[k]
>     >         end
>     >
>     >         This allows doing t:insert(foo) on any table t.
>     >
>