Re: Feature request: userdata slice

[Dirk Laurie <dirk.laurie@...>]

2015-08-19 14:01 GMT+02:00 Dirk Laurie <dirk.laurie@gmail.com>:
> 2015-08-19 13:49 GMT+02:00 云风 Cloud Wu <cloudwu@gmail.com>:
>>> The whole idea sucks, in spades. Userdata means user data.
>>> Lua is not supposed to know how its implementation details.
>>> The metatable is there to provide an interface. Light userdata
>>> is there when no interface beyond the ability to distinguish between
>>> instances is required.
>>
>>
>> I don't think you really understand the idea.
>
> Quite possibly. In that case, the idea is too complicated for someone
> like me to understand.

I think I understand it now, thanks to the messages of the past
16 hours. (In my timezone, people are just waking up.) The
OP's use case has been clouding the issue. What is being
proposed is much more versatile.

1. The type tag of a TValue is an C int, but only bits 0-3
(currently) are used to distinguish between types. The other bits
are available for purposes depending on the the type, e.g
bit 4 is used to distinguish between numbers and integers.
In the case of userdata, the distinction between light and
full userdata is already made in the last four bits so the
other bits are unused.

2. At the C level, userdata is just a block of memory of a certain
size. Full userdata is memory managed by Lua, light userdata
is memory managed by C. Programs in C can use and access
this memory as they please. For example, the actual contents
of the memory may be a union, in which there are many
different ways of accessing one and the same bytes.

3. We would like metamethods to take advantage of
variants, but the current ways of supplying the information
are not ideal for this purpose. If you store the variant information
in the userdata's own memory, the userdata is wired to be
a particular variant; if you provide the current variant as
a parameter, only __call has the ability to accept it.

4. The proposal is to expose the unused bits in the type tag
to the API which can then expose whatever it pleases at the
Lua level. By doing so, several aliases to the same uservalue
may be visible at the same time, all accessing it in different
ways. This will allow polymorphic usage of a userdata by
metamethods, in a way that could be distinguishable at
source code level by disciplined naming conventions.

The OP has repeatedly stated that the name "slice" is
not particularly appropriate. I agree. The names
lua_setsubtype and lua_getsubtype would make it
obvious what is being done. These routines might
restrict the setting of subtypes to userdata, although
subtyping nil would obviously be very useful too,
for all those people that have needed "empty" etc.

While not convinced at all by OP's use case, I agree that
a tool of this power will quickly inspire many ways of
using it.