Re: Userdata with methods *and* table access.

[Dimitris Papavasiliou <jimmyp@...>]

On Friday 15 October 2004 19:24, Lucas Ackerman wrote:
> Hello Dimitris, I'm afraid you're a bit late to the game here.  I'm sorry
> the lua-l group has ignored the points you wanted to discuss, but the
> simple fact is that Lua is a fairly mature language (more than 10 years
> old now) and the list has been over these issues very thoroughly in the
> recent past.
>
> If you do want to modify Lua, these are not difficult changes to make.
>
> I agree that the default indexing metamethod behavior could be simpler,
> but there are good reasons for the current design, notably the huge
> performance hit if __index and __newindex were forced all the time.  The
> prominent use of Lua in embedded platforms and games makes table
> performance more important than meta-feature convenience, especially since
> tables are the fundamental Lua data structure.

Hi Lucas,

that's what I thought initially too but it turns out not to be the case.  This 
is an excerpt from a post to a previous thread (entitled "Lua hacking 
wondering...") by Roberto Ierusalimschy:

---
> Wouldn't it be possible to store a pointer the the internal table
> structure of the metatable that is ssigned to each table/udata?  That
> way the cost of checking wether a metamethod exists would be one
> pointer lookup and some bit testing wich is negligible (plus maybe
> some overhead in lua_setmetatable)

This is already done. I don't think metatable access is a performance
problem in real applications.

> and we would be able to have our precious __settable ,__gettable and
> maybe __next metamethods.

The point is not performance. Whenever you set a __gettable metamethod
to a table, you cannot access that table except through a "rawget" call.
In other words, you already need some special way to access the table.
That is not much different than the use of a proxy. More important, it
is quite easy to encapsulate the proxy "pattern" inside a function, so
that anyone that needs to track table accesses just call that function
(see PIL, page 117).
---

Needless to say who he's answering to I suppose.  Anyway I don't have anything 
against proxy tables.  They're a relatively clean workaround I suppose but 
they could be avoided which would be even better.  Also attaching a pointer 
to a table for storing C data would make C<->Lua interfacing simpler and 
better for reasons I have explained (hopefully) in the initial post.  That's 
all I'm saying.

Of course it works as is and I can understand it if people think more 
pragmatically and don't want to sacrifice backwards compatibility for it but 
I also think it's worth it (although I'll have to rewrite everything too).

> However, I think this is a strong argument for increasing the ease of
> using proxy tables, since they are a prominent idiom in Lua 5.  I've been
> thinking about adding the following:
>
> 1) A table internals swap (or identity swap if you like) function to
> efficiently proxy a table without losing identity.
>
> 2) Having a per-table proxy-mode flag to force __index and __newindex use
> regardless of existing keys.  This is a kind of self-proxy or auto-proxy
> behavior.  It would be much cheaper than always checking metatables, and
> it doesn't require an extra table like the typical proxy idiom does.

I can't say I understood the first proposal but the second would work too I 
suppose.  I just don't see why we should keep a mechanism which implements a 
general feature (table/object 'overridability') not in the most 
straightforward and generic way but in a way more suited towards a specific 
application.

It's not terribly important for me either, from a practical point of view.  I 
just like Lua and I want to see it get even better.

--Dimitris