Re: Unified tables and userdata

[Rici Lake <lua@...>]

On 2-Oct-04, at 3:47 PM, Dimitris Papavasiliou wrote:

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

OK, a few comments.

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

>  This includes:
>
>  * All current metamethods
>  * Greater than, greater or equal (I just noticed these aren't there. 
> Why?)

because they can be implemented in terms of < and <=, avoiding (some) 
possible inconsistencies.

>  * 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).


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

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.


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

R