Re: Definition of table.insert

[Frank Siebenlist <frank.siebenlist@...>]

I believe that if we manage to separate the map and array metaphors of a lua-table, then we can live with nil for the array-personality.

I agree with David about the map and nil - it bothers me that I cannot distinguish an unassigned entry from a non-existing one. It would be great if that could be addressed.

However, for an array abstraction we may not need it. If we have an interface that allows us to introspect the array-personality as being of a certain size n, then we already know that all elements with an index of a positive integer up to n do exist, and a nil value implies that it hasn't been assigned - no ambiguity. To support that view, you have to be able to set the size independent from whatever values you present at creation time. 

I'm afraid that one has to define/agree-on the array-sematics that you want to support clearly before discussing the implementation.

-Frank.



On Jan 10, 2011, at 2:50 AM, David Kastrup wrote:

> Axel Kittenberger <axkibe@gmail.com> writes:
> 
>> Proposal a function table.icopy(table, src, dest, n) which replaces
>> the need for insert and remove.
> 
> One could instead just give table.insert a fourth argument defaulting to
> #table in case that one messes around with table bad enough that #table
> is not going to be a reliable end of range indicator.
> 
> But I don't see that this leads anywhere sensible.  If one wants to
> maintain tables with holes, one should create a _proper_ hole value
> different from nil and/or overload #table.  nil is _not_ a proper table
> element value, and it gives the table implementation a _wrong_
> indication about where the continuous section is supposed to end.
> 
> Putting nil in continuously maintained arrays will cause vast
> performance problems and unpredictabilities.
> 
> Just don't.  nil is there for a reason, and that reason is _explicitly_
> not being a table element.
> 
> -- 
> David Kastrup
> 
>