lua-users home
lua-l archive

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


On Mon, Jul 1, 2013 at 11:36 AM, Rena <hyperhacker@gmail.com> wrote:
> On Jul 1, 2013 2:05 PM, "Roberto Ierusalimschy" <roberto@inf.puc-rio.br>
> wrote:
>>
>> > 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?
>>
>> At last something new and worth a discussion. Does anyone see problems/
>> incompatibilities/etc. with this?
>>
>> (But what is "[to]"?)
>>
>> Keep in mind that #t would still be undefined for arrays with holes,
>> but holes would be much less frequent...
>>
>> -- Roberto
>>
>
> This seems like a good idea, but I feel like it might complicate the
> internals a bit. Are you proposing that nil is able to be stored in tables,
> and keys can be removed only by table.delete()? (In that case, why is #t
> still undefined when holes are present? Or are nil keys no longer holes?)

Under this proposal, nils are no longer holes.

> That could be useful, but also a bit confusing as it means a key set to nil
> and a key that was never set (or was deleted) are different things, but both
> have a nil value.

You can tell the difference with table.has().

/s/ Adam