[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: How to overwrite/implement '__len'?
- From: Clemens Hintze <ml-lua@...>
- Date: Wed, 14 Jun 2006 04:56:59 +0200
Doug Rogers schrieb:
Clemens Hintze wrote:
Thanks for your answer,
Yes, like the __gc metamethod (but for different reasons - see
http://lua-users.org/lists/lua-l/2006-01/msg00172.html), __len can only
be overridden by userdatum types. Experience has taught me that there
will be a good reason for such an apparent oversight. It may just be
performance; see http://lua-users.org/lists/lua-l/2006-03/msg00700.html.
I have already seen those both. I had only hoped that there would be any
other way than taking the table implementation of Lua and reintroduce it
as loadable extension with type() e.g. "object" only to get to a
functional __len(). Pity that! :-(
I like orthogonality and consistency. And Lua was one of the most
consistent so far (the other could be Tcl, IMO).
I don't see an easy way to avoid the cost of walking the metatable tree
for the case where __len is not defined.
You're right. Beside to attach something like 'meta flags' to a table
that could indicate, that there is a __len that should be taken, I would
also have no idea, how to avoid those costs :-(
But as it is only a small detail, I can probably live with it I mean :-)
Either I re-take the table implementation for implementing objects or I
will assign a 'size()' method to my table-build objects at Lua level.
The only confusing remaining thing would be, that one had to remember
that she should *not* take '#' to get the size of my rbtree instance.
And there will be no way to disable '#' for my rbtree ... *gnarz* :-/
But perhaps there are other issues. I was unable to find any further
discussion in the archives, but I seem to remember more than what I found.
Its okay, thank you anyway. It was at least a hint, that I had not
overseen something. Thanks again!