lua-users home
lua-l archive

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


2013/7/1 Thomas Jericke <tjericke@indel.ch>:
>
>>
>> If you want arrays with holes, there are basically only three different
>> workarounds:
>>
>> 1.  use nil for the holes
>>     pro: - saves memory for very sparse arrays
>>          - fits well with varargs and table.(un)pack.
>>          - no mapping from hole to nil required
>>     con: - needs explicit length field
>>          - needs metatable if you want `#` and `ipairs` to work
>>
>> 2.  use a sentinel value for holes
>>     pro: - can use `#` and `ipairs` without metatable magic
>>     con: - cannot handle large sparse arrays
>>          - does not mix well with {...} and table.pack( ... )
>>
>> 3.  use some specialized container class/object
>>     pro: - can't be mistaken for a raw table
>>          - can implement whatever policy you see fit
>>     con: - does not feel like a raw table
>>
> Actually I think if 1. would become part of the standard library it wouldn't
> be a workaround.
>
> Lets assume there would be a sparse array library. It would not replace the
> current one, as the current is maybe good for some uses (I hardly use it
> myself to be honest).
>
> The new "array" library would always use a metatable to store the length and
> would not use a sentinel. This new library defines __len and __ipairs etc.
>
(...)

I hope to make here a substantial different contribution on the entire
discussion here.
Couldn't a lot of ambiguity and unexpected behavior avoided by keeping
nil but introducing two new functions to the table library called
"table.has(t,key)" and "table.delete(t,key,[to])" - and dropping the
deletion via assigning nil?

I consider this a mix of Tim's request and the counter arguments
against another new value.
To sum it up, here's the behavior:
- nil is a valid key / value in a table and creates a new allocation
- the value of any key that does not exist in a table is nil
- a key/value can be deleted from a table with a function call that
takes care of erasing that value (we actually have table.remove which
has however a different meaning)
- Existence of a key can be checked with a special function call
Implications:
- arrays can contain nil and the #length operator works as expected
even when nil is involved
- a distinction between nil/empty can be made without introducing a new value
- unpack works as expected (see other mail by Mark Melling who was
confused here - just one example of many)
- Deletion is a more "conscious" operation that is not depended on
function argument values or whatever

I can understand both sides of arguments brought up in the entire
discussion here (I didn't read it all) but I think my points here
could make sense for both parties.

Cheers,
Eike