Re: Feature request: userdata slice

[Coda Highland <chighland@...>]

On Thu, Aug 20, 2015 at 6:35 PM, Philipp Janda <siffiejoe@gmx.net> wrote:
> Am 21.08.2015 um 03:16 schröbte William Ahern:
>>
>> On Thu, Aug 20, 2015 at 07:05:22PM -0300, Roberto Ierusalimschy wrote:
>>>
>>> Maybe I am missing something, but if we want to put some extra bits in
>>> 'TValue' to good use and solve the OP problem, maybe a better idea would
>>> be to introduce metatables for light userdata.
>>>
>>> There would be a limit on the number of different metatables that light
>>> userdata can have, but it would be a reasonable high limit [2^25] for
>>> typical uses of metatables. If we adopt this limit for all metatables in
>>> the system, we could gain some space in tables and full userdata, too.
>
>
> That won't work for userdata/table because of the `__gc` metamethod which
> should be invoked when no more TValues to the userdata/table are around (so
> we can't get the metatable from a TValue).
>
>>> (We could even gain individual metatables for numbers :-)
>>>
>>
>> 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).
>
>
> I don't know whether I understand correctly. Referencing the full userdata
> from the metatable of the lightuserdata will prevent the full userdata from
> getting collected, *but* it will require a per-object metatable and not a
> per-type metatable for the lightuserdata, so you would allocate metatables
> instead of full userdata for those `__index` operations, and we are back to
> square one.
>
> Philipp

Why would it need a per-lightuserdata metatable? All lightuserdatas
referring into a full userdata would share a metatable -- remember
that __index/__setindex gets the object being indexed into as their
first parameter.

It would require ASSIGNING a metatable per lightuserdata, but that's
not really all that bad.

/s/ Adam