lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Tuesday 11 January 2011 03:30:02 Dirk Laurie wrote:

> 3. The keys 1,2,3,...,n occur particularly often, and for our convenience,
>     a table constructor is provided that implicitly assigns those keys
>     so that we need only specify values.  A nil value given to that
>     constructor means: don't associate anything with that key just yet.
Also, my experimentation that setting a key's value to nil makes it as if that 
key had NEVER been assigned. Neither pairs() nor a next() construction will 
pull out a key that has been assigned the value nil.

> 6. Lua does not actually check that you have been law-abiding when you
>     do use these functions, but (except ipairs and to some extent #)
>     the result is undefined and you should not rely on any property
>     that in a particular implementation they have been observed to
>     possess.

7. Since presumably the programmer is the one who loads the table, that same 
programmer can either make sure the table is loaded such that #tablename and 
table.maxn(tablename) work as expected, or else the programmer can add new 
keys to the table to keep counts and the like. My view is that if Lua provided 
absolutely no table.length(tablename), table.maxn(tablename) or #tablename, it 
would be no big deal because the programmer could either: 1) count and do 
bookkeeping on the way in, or 2) use pairs() or next() to iterate all keys 
with non-nil values and do any counting, summing and bookkeeping.


Steve Litt
Recession Relief Package