Re: one more thing..

["Adam D. Moss" <adam@...>]

Adam D. Moss wrote:
> I wonder if this is related
> to the very few cases where Lua makes a distiction between
> table indices that are truly empty and table indices that
> have had nil explicitly assigned to them.

Just out of interest (this pertains to lua 5.0):

code:

   local function f(...)
      dump(arg);
   end
   f();
   f(nil, nil, nil);

output (Lua 5.0):

["(anon)"] = {  -- table: 0x829ced0
   n = 0;
};
["(anon)"] = {  -- table: 0x829d1f0
   n = 3;
};

That one's a confusing issue to resolve consistantly though,
and probably a special-case.  Sometimes it's nice to know
the highest non-nil integer index in the table (general
table usage) and sometimes we really want to know the
highest integer index we 'tried' to put an item into, nil or
not (the case of function parameters where we overload the
meaning of the parameters based on the number of parameters
we were called with).

That one might take an arg table with this 'unusual' meaning
of getn() and cheerfully pass it to a function which expects
the regular table meaning, can cause bugs and confusion.  It's
bitten me in the past, and combined with the implicit creation
of the 'n' index within the table itself, I've persnoally just
got rid of all my getn/setn usage, and I don't miss it at
all, adapting my usage to prefer ipairs() and pairs().
The only time I can't avoid using getn() is with arg tables,
to discover how many args we were called with.

--Adam