Re: A review of changes between 5.1 and 5.2-work3

[Peter Cawley <lua@...>]

On Fri, May 21, 2010 at 4:19 PM, Jerome Vuarand
<jerome.vuarand@gmail.com> wrote:
> Point 16 specifies that if __gc is set in a metatable after it's been
> assigned to a userdata won't make it called at collection. If the __gc
> is present during setmetatable, but is later changed, will the
> original or the new __gc be called at collection ?
A (non-nil) __gc field has to be present when the metatable is
assigned in order for the UD to be placed on the appropriate GC list
(the list of UDs with __gc). At collection time, the current value of
__gc will be called, provided that the UD was on the appropriate list.
Hence as long as there was a __gc, the new __gc will be called at
collection.

> Still about the point 16, and the point 23, the latter has the
> following code snippet :
>
>    getmetatable(newproxy(true)).__gc = print
>    os.exit(0, true) --> userdata
>
> However according to point 16, assigning print to __gc after the
> creation of the userdata (inside newproxy) shouldn't be registered. So
> is print really called in that situation (and contradicting point 16)
> ? Will newproxy be updated to be able to give it a __gc ? Or is it
> recommended to create a prototype proxy, assign it a __gc, and then
> clone it (by passing it to newproxy), the clone sharing the metatable
> and hopefully having its __gc acknowledged ?
newproxy(true) will return a userdata with a new metatable, and it
initialises the __gc field of that metatable to the value false prior
to setting the metatable. Hence as __gc is non-nil at the moment of
metatable setting, the new userdata will be placed on the appropriate
list. __gc is then changed from false to print, and so print will get
called at collection time.

> Also I'm a bit surprised by point 54: luaL_typerror wasn't really a
> typo, but rather a contraction. It was consistent with luaL_argerror
> (instead of luaL_argumenterror) in having 3 characters between "luaL_"
> and "error".
I'd argue that "arg" is a usual contraction of "argument", whereas
"typ" is not a usual contraction of "type".