[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Userdata with methods *and* table access.
- From: Dimitris Papavasiliou <jimmyp@...>
- Date: Fri, 15 Oct 2004 20:33:35 +0300
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.
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
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.