Yet another proposal for <toclose> (was Re: [ANN] Lua 5.4.0 (alpha) now available)
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Yet another proposal for <toclose> (was Re: [ANN] Lua 5.4.0 (alpha) now available)
- From: Sean Conner <sean@...>
- Date: 2019年6月27日 17:54:40 -0400
It was thus said that the Great Dirk Laurie once stated:
>
> I've been a Lua user for almost ten years, and I've succeeded in
> understanding and sometimes using every language addition in that
> time. Not so with <toclose>.
>
> My perceptions about it are:
>
> 1. It solves a problem encountered by a very small fraction of Lua users.
> 2. Although it looks like a property of a variable, i.e. a name, it is
> a property of the associated value.
> 3. All variables declared <toclose> must have a metatable with a
> __close metamethod, otherwise nothing different happens anyway.
> 4. Therefore they must be either tables or full userdata.
> 5. The 5.4 alpha syntax for it is the least ugly among various
> possibilities, but still ugly.
> 6. It runs counter to Lua's design goals of being minimal, neat and compact.
>
> In other words, <toclose> is feature bloat.
Reading this, I just had an idea. It introduces just one new keyword,
removes annotations entirely, and (I think?) introduces just a *bit* of
cognitive overload.
do
-- --------------------------------------------------------------
-- 'scope' is like 'local' in that the variable is local to the
-- current scope, but unlike 'local', the variable is closed at
-- the end. When we leave the current scope, each variable
-- declared as a 'scope' is checked for a __close metamethod, and
-- if it exists, it is called; otherwise, nothing happens.
-- --------------------------------------------------------------
scope f,err = io.open("foobar")
local x,y,z -- regular locals
-- -----------------------------------------
-- all variables of type 'scope' are closed
-- -----------------------------------------
end
The current behavior with for (the four parameter that is "closed") can be
kept.
> > However the ugly syntax for a constant declaration is the side effect
> > of this; and that is a heavy price to pay. Given that the constant
> > feature seems to have been added because it was 'free' - perhaps, it
> > shouldn't be added to the language.
>
> Agreed.
Unless we can get global constants (or constants in a table) then yes, I
agree, the <const> attribute doesn't seem to be all that useful.
Agreed.
-spc