RE: getn

[Reuben Thomas <rrt@...>]

> How about not giving it a name at all, but rather making it a hidden
> property of a table?  Then, if you want to get to the value, one would call
> a function like getn(table).  I wonder how much existing code that would
> break-- that is, how many people use table.n as a rough synonym for getn()?

I sometimes do, but I don't think there's any good reason to except when
you want to set it; you could always add setn(t, e), but this seems too
much like adding a special case.

> No matter what name you pick, *someone* will eventually toss data in a table
> that's the same name as this variable.  I love Lua, but this is one of my
> pet peeves of the language.  The size of a table should be an intrinsic
> property of the table-- not a member of the table.  I can see the value of
> making it optional-- but not the value of making it a member.

It'd be nicer though if this could be a property just like any other in an
object-oriented way, as it pretty much is at the moment, and not a "magic"
property as you seem to be proposing. I'm not sure what the answer is;
there's a tension between the use of tables as objects and as simple
tables.

I think that if you're likely to want a key called "n", then you shouldn't
be putting it in a getn-able table (which is generally a list). It's
sometimes nice to be able to put a list and other elements in the same
table, but unnecessary.

What would be nice is some way of protecting objects a bit, so you
couldn't overwrite an n field by mistake. Then, you would have to use
accessor methods to get at the underlying fields.