-1 on this. One of the advantages (for me) of userdata in Lua is that there is *no* language defined way that userdata can be modified. This means a C library can use Lua as the container for opaque data and be assured that whatever it stores there is not meddled with. If you want this sort of functionality on some specific userdata, then it’s pretty easy to expose an appropriate custom API for that purpose.
But we use full userdata rather than light userdata because full userdata is a gc object.
In many cases, we need reference the different parts of an object, but they are the same one object (to garbage collector). If we create dozens of userdata for them, we need more expensive works : cache these reference userdata in a weak table, put the root object in their uservalue, etc.
OK, but my comments apply equally to full and light userdata.
I’m not clear what your actual problem is, as you seem to be suggesting a solution without really saying what the underlying problem you are trying to solve is. What I *think* you are saying is that you wish to expose two distinct userdata values that have the same lifetime from a GC standpoint, but I’m not clear why you need to do this.
—Tim
|
