[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: [Proposal] _GETNAME upvalue
- From: "Soni \"They/Them\" L." <fakedme@...>
- Date: Tue, 22 Jun 2021 18:33:39 -0300
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. <firstname.lastname@example.org
> <mailto:email@example.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
> > Personally this seems a bit pointless because you can just use
> > 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
> dispatch, doesn't involve wrapping/unwrapping, actually handles
> (where other modules go through your module to access stuff, i.e.
> 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
> <firstname.lastname@example.org <mailto:email@example.com>
> > <mailto:firstname.lastname@example.org <mailto:email@example.com>>>
> > I personally don't see the use of it.
> > On Mon, Jun 21, 2021, 12:48 Soni "They/Them" L.
> <firstname.lastname@example.org <mailto:email@example.com>
> > <mailto:firstname.lastname@example.org <mailto:email@example.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.