RE: tables

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

This behaviour is not dangerous; it is expected.  What is dangerous is trying to use the result of the length operator on an array with holes.

In other words, you should never try #{nil, 2} or #{[2] = 2} in the first place.  If you do, you must expect an unpredictable result.

Furthermore, you cannot expect #{nil, 2} to always return 2, nor #{[2] = 2} to return 0.  As I said earlier, the length operator only gaurantees a predictable result with arrays with no holes, so later versions of the interpretter could have #{nil, 2} return 0 and #{[2] = 2} return 2.  According to the definition of the length operator, both 0 and 2 are valid lengths of {nil, 2} and {[2] = 2}.



-----Original Message-----
From: lua-bounces@bazar2.conectiva.com.br on behalf of D Burgess
Sent: Sun 3/5/2006 5:39 PM
To: Lua list
Subject: Re: tables
 
I think the behaviour is  dangerous.

> =#{nil,2}
2
> =#{[2]=2}
0

The behaviour changes depending on the syntax of construction.

David B

On 3/6/06, Dolan, Ryanne Thomas (UMR-Student) <rtdmr6@umr.edu> wrote:
>
> 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.
>

<<winmail.dat>>