 |
lua-l archive |
|
|
||
|
On 06/07/2019 17:58, Andrew Starks wrote:
On Jul 5, 2019, at 16:24, Coda Highland <chighland@gmail.com> wrote: 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 another thread... <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, thumbs up! 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? -Andrew
(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).
@Andrew: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.
Cheers! -- Lorenzo