Re: PiL2, ch 28.3: Adding Lua methods to an array?

["Daniel Collins" <daniel.collins@...>]

> Sounds like our approaches are very similar, but I did not explicitly 
> think about inheritance issues so far...

By inheritance, I am referring to the attempt to make the table behave
like the userdata. In my initial approach I didn't have this, I just
aggregated the userdata into the table, then accessed the userdata
inside the table methods in much the same way as I would use a private
member in a C++ class. I ended up with things like this:

function screen:new(screenUD)
	local s = { __ud = screenUD }
	-- do more stuff to s
	return s
end

I think the crux of the matter is whether the C code is open to
modification or not. If it is, then the metatable approach works nicely
since the code can be altered to handle receiving a table instead of the
userdata on the stack. 

I would love to see a solution that lets a table act as though it is a
particular userdata object for the case where the userdata C code cannot
be altered. That would be really cool.

In my project, I am tempted to write my own check_udata function that
first looks for the userdata, but if a table is at the specified
location it will attempt to find the userdata in the field __ud instead.
This way my userdata methods will work with either the userdata or a
table with __ud set to the userdata. This should give me a lot of
flexibility in how the userdata gets used by the client code.

Thanks for the idea :-)

- DC