Re: Empty? No. Array? No. Has? Yes.

[Sean Conner <sean@...>]

It was thus said that the Great Rena once stated:
> 
> It does seem awfully strange to me: Lua's strings can contain any byte,
> because they store the length separately from the string data. This is
> generally considered a good thing, especially compared to C strings - it
> takes length lookup from O(n) to O(1) and allows them to contain arbitrary
> binary data. Yet Lua's arrays don't have this same feature, and instead use
> the C-string method of a magic terminating value that can't appear anywhere
> in the array, which limits what they can store. (Though I assume length
> lookup is still O(1) in this case!) And as a "bonus" it makes the #
> operator's behaviour somewhat strange as well - not always very reliable or
> useful, and apparently rather confusing to some people.
> 
> People keep commenting "oh look table.setn() is back", and I keep wondering
> if that's really a bad thing. What was so bad about it that it had to be
> removed? To me, storing the length separately from the data seems like the
> most sensible idea.

  I like this idea.  Given that Lua already has a table.remove() function
that operates on the array portion of a table, then this could be a very
workable solution.  

t = { 1 , 2 , 3 , 4 , 5 , 6 , 7 }
print(#t)	-- prints 7
t[4] = nil
print(#t)	-- would still print 7

table.remove(t,4)
print(#t)	-- would print 6

t[#t + 1] = 8
print(#t)	-- would print 7

  -spc (And would remove the whole "holes" issue in Lua ... )