Re: table insertion [was: Lua 5.1 (work2) now available]

[Rici Lake <lua@...>]

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, 
> etc. is
> a question that would need more consideration.

It used to be table.n; changing "n" to "length" doesn't seem to make 
much
difference. :)

Some other comments:

I personally like (or have become accustomed to) the semantics of 
getn/setn,
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
OK.

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 
functions
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 
deliberately
missing because not exposing them allows for compile-time 
optimisations, for
example in the case of @n and @meta.

Just something to think about. Feel free to cruelly reject it out of 
hand.

R.