[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: tables
- From: Chris <coderight@...>
- Date: Sun, 5 Mar 2006 19:05:34 -0500
On 3/5/06, Dolan, Ryanne Thomas (UMR-Student) <rtdmr6@umr.edu> wrote:
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}.
Can someone define what a "hole" in an array is? Why can't I have
an array with nil values in it? The current behaviour suggests
those are not holes. However, the documentation gives a vague
explaination that says nils *might* be "holes". But again,
judging by the actual behaviour, setting a particular entry in an array
to nil is not considered a hole. I think that's probably a good
thing because it allows me to build an array and set some values to nil
as a placeholder.
However, if a change in implementation could change this behaviour that
makes me feel uneasy. This whole issue makes me realize that Lua
really needs an official well defined language specification to be
taken seriously.
--
// Chris