lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

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

 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.