lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On 3/5/06, Dolan, Ryanne Thomas (UMR-Student) <> 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