> 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
Even if I think the cosmetics aren't perfect I wouldn't complain about it staying as-is. I think what's currently there is good enough.
I haven't been following everything. Some of the rabbit holes have been too deep for me, so I've been tuning out threads that start going into too much detail about unnecessary alternatives.
I would probably end up using it more than you, at least in terms of uses per kloc. A lot of it is going to have to do with use cases -- I would turn to <toclose> in MOST places I would have otherwise used an IIFE. And it would really cut down on boilerplate for things I do a lot.
So in my opinion, my answers to your question are:
Yes, it solves a real problem worth solving. Because there are techniques you could have already used it mostly just makes it easier and more efficient, so it's not a critical feature, but the cost of providing it appears to be small enough to make it worthwhile.
Yes, it works for that purpose as-is.
No, I don't see a way it could break any existing scenarios; there's one edge case that it introduces that could possibly break (resolution of multiple errors in the callback) but C++ programmers are already used to the notion that you're not supposed to do that.
Yes, given its use cases it's clear and the syntax fits the purpose, but the name "close" is insufficiently broad because most of MY uses for it don't have anything to do with closing anything.
/s/ Adam
