lua-users home
lua-l archive

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


在 2017/3/23 19:21, Tim Hill 写道:
>
> So I’m not not sure how they are different?
>
> —Tim
>
>

I mean, sure, I can make them the same semantic for the Lua side, but the difference comes at the binding layer. and I was not saying which way is better than the other. different problems need different solutions.

for instance, consider the APIs in the following script,

------------------------------------------------

   local obj1 = get_object_by_id(some_id)
   local obj2 = get_subobject_by_name(obj1, some_name)
   local obj3 = get_buddy_object(some_object)

------------------------------------------------

most of the time, an object is just an opaque pointer returned by the C library and points to some internal data structure. assume I don't need Lua's gc to manage lifetime, the binding layer can be trivially written (or auto generated) if light userdata is used to represent the objects. but more than often, there could be many different binding types and I want to set metatables on them, or the host program might use light userdata for other purpose, so I have to use full userdata, then store the pointer itself into the full userdata.

sometimes, the script only use == and ~= for equality test so the __eq metamethod might be sufficient. in other cases, the script need to store the userdata as table keys, so the binding layer need to keep track all the full userdata already created, and map C pointers to full userdata. I usually do this via a (weak) table, whose values are those full userdata containing pointer values, and whose keys are, well, pointer themselves hashed as light userdata.


-- 
the nerdy Peng / 书呆彭 /