Re: [ANN] Lua 5.4.0 (alpha) now available

[Patrick Donnelly <batrick@...>]

On Thu, Jun 20, 2019 at 1:24 PM Coda Highland <chighland@gmail.com> wrote:
> On Thu, Jun 20, 2019 at 3:16 PM Patrick Donnelly <batrick@batbytes.com> wrote:
>>
>> Hi Soni,
>>
>> On Thu, Jun 20, 2019 at 12:18 PM Soni "They/Them" L. <fakedme@gmail.com> wrote:
>> > On 2019-06-20 4:06 p.m., Hugo Musso Gualandi wrote:
>> > > In Python the equivalent metamethod is called __exit__
>> > >
>> > > (There is also a corresponding method called __enter__, which is called at the start of the scope)
>> > >
>> > >
>> > >
>> > > >Actually it would be nice if someone could come up with a word that
>> > > >coul
>> > > >express the real concept clearly. For example: "at_scope_end" (or and
>> > > >"__at_scope_end" as a metamethod. Of course those are UGLY.
>> > > >
>> > > >Maybe "atend"? It's more explicit than "toclose" since actually
>> > > >describes that something happens when execution flow reaches the "end"
>> > > >keyword. "__atend" is not bad as a metamethod.
>> > >
>> >
>> > local <with> foo = bar --> calls bar's __enter metamethod?
>> > end --> calls bar's __exit metamethod?
>> >
>> > this also has the benefit of handling nested scopes as well, I guess?
>>
>> We don't need Python's cumbersome "with" semantics as Lua has real
>> variable scoping. See also [1].
>>
>> Also thinking about [2] more, where I proposed "bind" instead of
>> "toclose", I'm wondering if Lua should embrace binding the value's
>> lifetime to the variable (local) by calling __gc instead of __close.
>> Is there a good use-case for a value whose lifetime persists after
>> __close? If Lua calls __gc in a deterministic way, it resolves the
>> same issues and it can mark the value such that it no longer needs the
>> extra __gc cycle for finalization (IIRC how that works).
>>
>> [1] http://lua-users.org/lists/lua-l/2018-07/msg00463.html
>> [2] http://lua-users.org/lists/lua-l/2019-06/msg00405.html
>>
>> --
>> Patrick Donnelly
>>
>
> I disagree with tying this feature to the garbage collector. The current design is recursive; every opening has a corresponding close. Making it part of the garbage collector would mean that no matter how many openings you have, there will only ever be one close.

Current design doesn't have an __open so I don't really see how a
recursive open/close could be effectively used when only __close is
called.

If you're thinking about recursive locks, that's still very possible
with proxy "locker" objects that exist only for the duration of the
scope.

-- 
Patrick Donnelly