lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Am 20.08.2015 um 05:09 schröbte Tim Hill:

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?

I can't answer those. And I'm afraid that even if this discussion leads to something, it will probably be too late for the OP's current project, so I'm more interested what could be done with the proposal in the future.

The proposed user-defined tag for userdata has many similarities with pointer types in C. You can have non-const and const pointers to the same C object, and the pointers can have different types (this is more useful for C++ where this may influence method resolution). The user-defined tags could also be useful for other types. The most obvious example is lightuserdata where it could provide some more type safety. But you may also want to have different types of integers, e.g. file descriptor integers, that you can check for specifically in your C code. Or type-safe enums (but in this case you'd need to specify how arithmetic operations affect the tag of the result).

This sounds oddly familiar. Could it be that we already had a similar proposal in the past (not for full userdata, though)?


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

I'm a bit confused about this: The proposal was never about accessing the internals of userdata. And I agree that this would be a bad thing, *because* it can't be generic. Generic on the other hand is good. Generic means potentially useful in a lot of situations.


—Tim


Philipp