value sematics of metatable (Was: Re: Feature request: userdata slice)

[Wang Xavier <weasley.wx@...>]

2015-08-21 10:38 GMT+08:00 云风 Cloud Wu <cloudwu@gmail.com>:
> William Ahern <william@25thandclement.com>于2015年8月21日周五 上午9:16写道：
>>
>> Yes, that sounds like a genius idea! It took me awhile to think through
>> all
>> the implications. IIUC, the OP could just generate a single unique
>> metatable
>> for each full userdata object he wants to clone. He stores a reference to
>> the full userdata object in the metatable; the lightuserdata value becomes
>> the index into the full userdata (or some other object it references).
>
>
> At first, I like this idea :)
>
> If we don't care the lightuserdata's life time , we can share the unique
> metatable for each full userdata type .
>
> Put a weak table into metatable to reference all the live userdata for safe.
> When we need access lightuserdata , check the table first to verify whether
> the userdata it refer to is still alive.
>

There is a better way to do this. It need to complete change the
metatable sematics of Lua.

Now, Lua metatable is attacked to object, it means, only (some of)
true object (table, userdata) can have true metatable. But, what about
attach metataeble to ALL value? that means, the metatable field of
table and userdata can be dropped. All value has the same way to get
it's metatable: use the extra bits of type field of value on stack or
in table, function upvalue, etc.

In this way, a userdata can have different metatable as different
value. you can just push original userdata to stack, and set a
different metatable for this value. the new metatable will handle the
get/set from userdata object. you needn't push a lightuserdata.

In this sematics, all values can have different metatable. all
operations, except explicit call lua_setmetatable, will not change the
metatable of value. so the most behavior will be the same, except
this:
local t = {}
setmetatable(t, { ... })
print(getmetatable(t)) --> nil!!

metatable no longer set to table t, but to variable t, in this
situation, only the argument of setmetable changed the metatable,
after that, this value is dropped by function return, so the only way
to set a metatable in Lua must be:

local t = {}
t = setmetatable(t, {...})

then, debug.setmetatable is useless can be delete. all values can have
a metatable. it means Lua support JS style function object: a function
that bind with a table, can save things into this table.

all Lua values: nil, boolean, number, string, table, function, thread,
userdata (full/light) will have same mechanism to handle metatable, no
need Table pointer into gc objects.

then, true gc object can have __gc meta field, e.g. string, table,
function, thread, full userdata. not only table and full userdata.

metatable can be the "sub type" of values. two value are equal when
they have the same type and value, but two value rawequal when they
are equal and have the same metatable. with this rule, a table can
save the exact same value as key, if they have different metatable.

this may be the huge completion of Lua's metatable concept. Lua will
have a simple, powerful and conformably metatable concept. I hope we
can see this happen in Lua 5.4 :)


-- 
regards,
Xavier Wang.