RE: tables

["Dolan, Ryanne Thomas (UMR-Student)" <rtdmr6@...>]

The length operator only guarantees a predictable result in the case of an "array" without holes, like: {1, 2, 3, 4, 5}.  If there are any holes at all, then you can't rely on the # operator to give you the result you expect.  This is why the manual is a bit confusing; it gives a definition that is always valid, but not really useful except in the special case of an array without holes.

So, your experiment with {nil, 2, 3, 4, 5} gives you a valid result (according to the manual's definition) but it isn't a useful value.  This is not a bug at all, but an optimization.

-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br on behalf of D Burgess
Sent: Sun 3/5/2006 5:05 PM
To: Lua list
Subject: Re: tables
 
It would seem that we have the "never assigned nil" and
the "assigned nil".

David B

On 3/6/06, Chris <coderight@gmail.com> wrote:
>
>
>
> >
> >
> >
> > What I find interesting is that an explicitly set nil value is not
> considered a "hole" in the table.
> >
> > According to the documentation that shouldn't be.  A bug?
>
>
>  By the way, I find the documentation wording very confusing:
>
>  The length of a table t is defined to be any integer index n such that t[n]
> is not nil and t[n+1] is nil; moreover, if t[1] is nil, n ***may*** be zero.
> For a regular array, with non-nil values from 1 to a given n, its length is
> exactly that n, the index of its last value. If the array has "holes" (that
> is, nil values between other non-nil values), then #t ***may*** be any of
> the indices that directly precedes a nil value (that is, it ***may***
> consider any such nil value as the end of the array).
>  It _might_ consider a nil the end?  Well, does it or does it not?  And if
> it can change I think that needs to be made clear.
>
>  --
>  // Chris
>

<<winmail.dat>>