Re: new "empty" value/type in Lua?

[Hisham <h@...>]

On 2 July 2013 15:57, Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:
>> That's why I suggested to have a new standard library "array". It
>> won't be a new native Lua type. It's more or less just a standard
>> metatable for array type tables. The only difference between an
>> array and a sequence is, the array stores its length 'n' explicitly
>> and therefore allows to have nils in it. Also the length is always
>> set explicitly at construction or by calling setlength(n).
>>
>> The metatable defines __len and __ipairs: The # oparator will always
>> return n. The __ipairs always iterates from 1 to n, and doesn't care
>> if there are nils in its way.
>>
>> This is the minimal functionality needed. One could think of more
>> options: You can override the __newindex to only accept keys between
>> 1 and n. If setlength(new_n) is called, all elements after new_n
>> become nil, if new_n < n. But these would just be extra features to
>> make life easier.
>>
>> It has been said, such solutions are already possible. So maybe the
>> only thing left to do is to define the "standard" solution.
>
> Is something like this enough? (Note that 'n' is *not* hidden; I do
> not think hidden stuff is good in the end...)

I share Enrico Colombini's view:

> That would probably be the cleanest solution (assuming there is a problem,
> which I am not sure of).

I've never had a problem with "arrays with holes" myself because I
think it's more of a matter of how you look at your tables. But it's a
recurring discussion, and I'd support a solution even if only to end
those debates. :) Especially such an elegant/minimalistic solution.

Come to think of it, if it did get into standard Lua, I'd even throw
around the idea of merging array.new() and table.pack(). If we had the
notion of sequence tables with n and a metatable "in the language", it
would make sense if table.pack() returned one, and then it's the same
as array.new().

(I guess if I had a table.pack() which gave me an ipairs()-ready table
(ie, handling nils), I'd probably never use select() again. Handling
variadic functions with `for i, v in ipairs(table.pack(...))` would be
sweet indeed.)

-- Hisham
http://hisham.hm/