Re: Unified tables and userdata

[Dimitris Papavasiliou <jimmyp@...>]

On Friday 15 October 2004 00:02, Rici Lake wrote:
> > 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.
>
> Metamethods are not just for tables. They include arithmetic
> operations, for
> example.

What I mean with "every operation that can be performed on a Lua table or 
object with table-like interface" is what is syntactically possible in Lua, 
including arithmetic operators, function calls etc.

> >  * Next
>
> As I have often argued in the past, next() is not the appropriate
> primitive; if there is an appropriate primitive, it is pairs(), which
> returns a next() closure. (The fact that next() is often a closure
> rather than a self-contained function is the reason for pairs() being
> the appropriate primitive.) However, many table-types have more than
> one iteration model, and the use of "for k, v in table" is apparently
> deprecated in favour of "for k, v in pairs(table)", which suggests that
> it is the function pairs() which ought to do the metatable lookup (for
> the 'default' iteration schema).

Isn't pairs implemented on top of next?  lua_next() is the only function 
available in the API.

> The current behaviour is more efficient and often exactly what is being
> looked for, particularly in the case of __index. (In the case of
> __newindex, the point is arguable.) The use of a proxy table is not
> really a "trick"; it is a Lua idiom :) Of course, metatables applied to
> userdata already do exactly what you want.

In what way is it more efficient?

Also it might be useful in many cases but Lua is supposed to be a general 
purpose language and what I'm proposing seems to me more general. The __index 
behavior you're referring to can probably implemented with something like 
this:

if (!strcmp(lua_tostring(l, 2), "foo")) {
    ...
} else if (!strcmp(lua_tostring(l, 2), "bar")) {
    ...
} else
 lua_rawget(l, 1);

where foo and bar are "special" values and everything else isn't.  This code 
is pretty simple and logical and also note that you can still use the foo and 
bar table fields to store useful data.

On the other hand the current approach often needs the use of idioms which can 
complicate the code and also increase list traffic.

> > 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.
>
> This is a possibility. I personally prefer a model where a userdata has
> an (optional) associated table, which I find quite convenient. Patch
> available upon request.

Why do you want tables and userdata to be different concepts? In your approach 
you unify tables and userdata but still keep simple tables around.  If memory 
consumption is the reason you could somehow request whether you want a table, 
a userdata or a full pair on object creation but then again userdata and 
tables aren't supposed to be particularly lightweight in the first place.

Dimitris