Re: Feature request: userdata slice

On Aug 19, 2015, at 7:00 PM, Philipp Janda <siffiejoe@gmx.net> wrote:

Am 20.08.2015 um 00:54 schröbte Tim Hill:

On Aug 19, 2015, at 3:06 PM, Philipp Janda <siffiejoe@gmx.net> wrote:

Yes, close. But you are mixing two different approaches here. For the tag-approach `pInterior` should be an integer tag. The pointer won't help you much because you don't know what to do with it. It lacks any type information (it's a void pointer, and the metatable is that of the base object). You could try to calculate the difference between `pRoot` and `pInterior` to figure out where you are actually pointing to (won't work if you are dealing with a union), but an id is simpler.

But the charm of the proposal was that no memory needs to be allocated to push the userdata with a different tag. Allocating a new userdata for every `__index` access is wasteful, and you really should do some caching using a table (I'd choose a non-weak table in this case, though).

However, the tagged userdata approach could be useful in some circumstances nevertheless, e.g. for simulating pointers to base-classes when binding a C++ library.

Quite possibly, but I’m not clear on what exactly the OP wants to DO with the various pointers/references/IDs into the "big chunk of stuff". I’m not clear on what the lifetime of this big chunk of data is .. it appears from his later posts to exceed that of any given Lua VM, in which case what was the need for GC management and full userdata at all? I get a hint from this thread that the OP wishes to have a very generic reflective access model into the dataset (think DOM), but again the use cases are not clear to me from this thread.

To get any further I’d like to see several basic questions answered:

1. What is the lifetime of the external data compared to the lifetime of any of the accessing Lua VM?

2. What entity interprets the external data (Lua or C code) to impute it’s structure and any deducible descriptive metadata?

3. How does the data need to be presented to Lua for processing (numbers, strings, opaque data etc)?

4. What are the operations that Lua needs to perform on this data, and what tradeoffs are there between size and speed for these operations?

Regardless, I stand by my original post, introducing any *generic* mechanism into Lua to access the internals of userdata would be a bad thing.

—Tim