Unified tables and userdata

[Dimitris Papavasiliou <jimmyp@...>]

I'm reposting this because I initially posted it as a reply to an older thread 
by mistake:

This is a proposal for some relatively small (although not backwrds 
compatible) changes to the way tables ans userdata, which are in essence one 
and the same thing, are handled in Lua:

1. 'Simpler' metatables
Metatables should simply include fields for every operation that can be 
performed on a Lua table or object with table-like interface, thus rendering 
it completely generic and user-programmable. This includes:

 * All current metamethods
 * Greater than, greater or equal (I just noticed these aren't there. Why?)
 * Next
 * All other operations defined on tables/objects I haven't thought off.

More importantly make these metamethods *always* override default ones. This 
is the simplest and most general way on which everything else can be built 
and concerns index/newindex AFAIK. I can see no reason for their current 
behaviour which requires a trick to bypass.

Also note that according to previous posts there are no performance hits for 
any tables with no metamethods since checking whether a metamethod exists 
does not (in the current implementation) require a table lookup.

2. Unified tables and userdata
These are way to similar to be different things. A table could have a pointer 
associated to it for user data. This would greatly simplify creating objects 
that are Lua interfaces for C entities. Let's for example consider a 
tree-like structure in C for which we want to have a lua interface (like a 
scene graph for graphics people or any graph for that matter). We have a node 
containing our data and a list of links like:

struct node {
 int i, j, k;
 float f, g, h;

 struct foo *foo; /* these are all pointers to userdata      */
 struct bar *bar; /* for which references need to be kept */
 struct node *children;
} node;

A table/userdata pair would be perfect for this since you would be able to set 
its index/newindex metamethods to get/set the values of the internal C struct 
and also use the table to hold the references for its children and the 
objects named foo and bar. Of course you'd still have to update the linked 
list *children yourself (if you need quick traversal of the graph that is) 
but this is not Lua's problem.

The current implementation requires me to keep an extra table for each 
userdata (for the children) and a reference to it and also references to the 
foo and bar objects, which makes the C glue code more 'complex' and 
'unnatural'. This may not be the best example but it is 3AM and what I wanted 
to point out is that since user objects in Lua are implemented like tables 
they should *be* tables (as everything else in Lua:) ).

This is of course only for "heavy" objects for which the extra space to hold 
the table structure per userdata (a few bytes that is) would not be a 
problem. As for light userdata they could simply be renamed to userdata 
(remember userdata would now be called table) since they're not objects but 
simple data pointers.

This would not allow me personally and others I believe to do something that 
can't be done now but the C code needed to interface to Lua would become 
simpler and also more logical.It would of course also completely break 
backwards compatibility but this is why I like Lua anyway; it's not afraid to 
do so if it'll get better and simpler.

Dimitris