Re: Quest: real world "Lua array with holes" usage

[Daurnimator <quae@...>]

On 21 July 2016 at 08:13, Rodrigo Azevedo <rodrigoams@gmail.com> wrote:
> In face of recent (long) discussion about "Lua arrays", I would request a
> simple few lines of real world examples where the use of "Lua arrays with
> holes" is significant.
> I known that, intuitively, the length operator # should return the "size" of
> the array, but I'm not able to find significant use cases where "holes" are,
> in fact, a real problem other than a *simple* algorithm redesign.
>
> For my particular use case I made heavy use of "sparse things", from which
> Lua tables are awesome, where all computations are based on the keys,
> namely, with pairs() or indexing the relevant key. Also, I use "proper
> sequences" with Lua tables. In this case, table.pack and table.unpack are
> symmetric, and the relevant computation is given by the "order" of the keys,
> namely, with table.insert, table.remove, table.move etc that is by default,
> in this case, simple to understand. I never ever used a "Lua array with
> holes", where the ordering, or existence, of the keys is indeed relevant for
> computation. Precluding the use of __len or misbehaviour of  #.
>
> Could you help me giving a (real world) counterexample?
>
> --
> Rodrigo Azevedo Moreira da Silva

The place it usually comes up for me is when keeping arguments across
a callback-style api:

local function foo(...)
    local args = {...}
    do_something_async(function()
        -- called when done
        my_other_function(x, table.unpack(args))
    end)
end

If the argument list contains a `nil` then the above will fail for some inputs.
Hence you end up needing to use `table.pack` or `select("#", ...)`