Re: Protected tables proposal

[Dimitris Papavasiliou <jimmyp@...>]

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.
This 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