[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: table insertion [was: Lua 5.1 (work2) now available]
- From: Rici Lake <lua@...>
- Date: Thu, 4 Nov 2004 11:34:43 -0500
On 4-Nov-04, at 11:21 AM, Mark Hamburg wrote:
Actually, if __index handles length, you can use table.length to invoke
code. I do think, however, that it would probably help to give message
sending it's own metatable support so that t:m() would go through
__callmethod (for example) rather than __index. This could reduce the
complexity of __index metamethods. How this works with inheritance,
a question that would need more consideration.
It used to be table.n; changing "n" to "length" doesn't seem to make
Some other comments:
I personally like (or have become accustomed to) the semantics of
although I think it would be better if the value were stored in just one
place and accessible easily, and without the table library.
"*" does not strike me as intuitive for an operator yielding the length
of a table. "#" would make more sense to me, but see below.
Whatever operator is used to return the "length" of a table, it would
be nice if it also could return the length of a string.
David Given's point on field lookups vs. method calls makes a lot of
sense to me. Sol does this, as I understand it, and it seems to work
While I hate to propose new syntax, and this is possibly even more
confusing, I have the misty idea of "attributes" (or properties) which
might be more generalisable. The basic syntax, using "@" for "@tribute"
(which really only works in English, sorry) would be something like:
t@n -- "length of the table" (or t@length if you prefer)
t@n = 3 -- set the length of the table
s@n -- length of a string
s@n = 3 -- error: attempt to change immutable object
t@meta -- metatable for table
u@meta -- metatable for userdata (if not blocked)
t@meta = newmeta -- set metatable for table
u@meta = newmeta -- error: cannot set metatable for userdata
obj@attribute -- returns obj@meta.__attr(obj, attribute)
obj@attribute = v -- calls obj@meta.__setattr(obj, attribute, v)
The assumption here is that there is a table of default attribute
for each primitive type (which is how t@n and s@n would be handled.)
Exposing the set of attributes as a table, though orthogonal, is
missing because not exposing them allows for compile-time
example in the case of @n and @meta.
Just something to think about. Feel free to cruelly reject it out of