[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Another option for closing variables
- From: Lorenzo Donati <lorenzodonatibz@...>
- Date: Fri, 12 Jul 2019 11:36:39 +0200
On 06/07/2019 17:58, Andrew Starks wrote:
On Jul 5, 2019, at 16:24, Coda Highland <firstname.lastname@example.org>
I mean, yeah, I don't think angle brackets are an ideal syntax for
it, and "toclose" is something of an awkward name, but everything
else about it I think is sound.
Not sure where to stick these comments, so instead of starting
<toclose> solves a problem I’ve actually had: getting rid of a big
resource in a deterministic way, regardless of error, not waiting for
__gc. Since this solves that problem in a way I can understand,
Making a wild guess: in 10k lines of code, I may use something like
this in 5 places, almost always in library code, not application
scripts. I don’t mind it being verbose or even a little awkward. Some
may argue that the syntax should stand out and be overly clear (no
multiple assignments that might make order of release slightly
ambiguous or at least something I may have to look up). When handling
resources and memory, I like to go slow and careful because I make
lots of mistakes.
As for the word, “close” makes sense enough to me because that’s what
I care about (and release is a longer word to type). I don’t care
that the tiny little variable is garbage collected. I care that the
big giant resource that the variable is holding on to is
closed/released as soon as possible.
This looks like a nice enough mechanism to do that.
I’ve read most, but not all, of the debates around this. I have not
gotten the sense that the controversy is because this doesn’t work
for the intended purpose; just that it’s awkward or that people
wished it worked differently / more flexibly.
Does it solve a real problem that is worth solving? Does Lua 5.4’s
<toclose> feature work for that intended purpose? Does it break
anything? Given its use cases, is it clear enough and does the syntax
fit for the purpose?
(Also related to Coda Highland's reply to your post)
BTW (@Coda): yes I, got almost lost in the rabbit holes, too! So I may
be repeating things here (sorry then).
You make a nice analysis of the situation, and you come to the
conclusion that a little syntactic/semantic awkwardness is acceptable,
because the problem this new mechanism solve "elegantly" (essentially
RAII) is very important and critical in resource management.
I agree to a point: we would really benefit a clean mechanism for RAII.
The problem I see with the awkwardness is that it may bite us heavily in
the future (5.1 "module" thing, anyone?).
I would really prefer to wait a little more for such a feature until Lua
Team has come up with a smoother mechanism.
The ugliness of the "toclose" name is just one thing. The not-so-nice
interaction with multiple assignment and other idioms is yet another
one. Who knows which kind of antipattern could come up after we use it
for a while.
And, BTW, readability in code is not to be underestimated. Especially in
resource management. If the code is managed by multiple persons,
especially over a long span of time, nasty error could be introduced
because of miscommunication (high level code is more a mean of
communication between people - even a programmer and himself - rather
than a way to give a computer orders).
I almost feel that /there has to be a better way/ and the current way
doesn't feel quite right.
For example, the fact that a /variable/ is marked, but /an object/ is
"closed" (using its metamethod) is something smelly. The whole point of
RAII is to make very explicit the connection between a resource and the
code that handle its release and the time this code is run.
The current Lua 5.4 mechanism is not so explicit, IMO.
For that matters, I'm beginning to feel a sort of "defer..end" block
could be a better, more general, more explicit, solution.
I love Lua ability to keep the code clean (and clear) in common use
cases (although it has its dark corners, e.g. the general for loop
syntax - maybe it's me, but I keep forgetting what are those pesky three
parameters after "in" keyword <ugh>). I'd like to stay that way.