Re: block-scope finalization
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: block-scope finalization
- From: Sean Conner <sean@...>
- Date: 2016年1月14日 12:01:20 -0500
It was thus said that the Great Roberto Ierusalimschy once stated:
> What is wrong with the following proposal?
>
> local <some mark to be invented> name = exp
>
> Unlike a regular 'local' declaration, this one must define only one
> variable and it must be initialized. (Both restrictions could be easily
> removed; they are more about programming style.)
>
> When the local 'name' goes out of scope, then:
>
> 1 - if its value is a function, that function is called (no parameters)
I don't think this is a good idea. For example:
do
local magic print = print -- because I heard this was faster!
print("hello")
print("goodbye")
end
print() gets called an extra time and an extraneous line of output is
generated. I purposely picked a function I know has a side effect when no
parameters are called to show the issue here. We don't know *which*
functions will be assigned to a local value. So now what?
do
local magic print = print
print("hello")
print("goodbye")
print = nil -- WTF?
end
Another issue---how to __call and __close interact?
do
local magic foo = {}
setmetatable(foo,{ __call = function(self) ... end })
foo(3)
end
foo has call semantics, so is it
foo(nil)
or
getmetatable(foo).__close(foo)
Yes, it might seem clear that __close() happens because foo is a table,
but a reasonable case might be made for the confusion.
> 2 - if its value is a table/userdata, its __close (or some other new
> name) metamethod, if present, is called.
This I don't have an issue with.
-spc