 |
lua-l archive |
|
|
||
|
Am 01.07.2013 21:05 schröbte Coda Highland:
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... -- RobertoThis 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.
... but holes are nils. Or stated differently: There are explicit nils, which are part of a table, and implicit (deleted or never assigned) nils, which are still holes. One question is: Should accessing explicit nils invoke __(new)index metamethods?
I'd argue that if you want nils as part of tables, then go all the way, and remove nil as a default value. Throw an error when accessing a non-existing field instead. No need for strict.lua any more, yay! You could simulate the old behavior using a nil-returning __index metamethod.
Anything in between seems messy, IMHO ...
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().
table.has() and table.delete() would be essential functions not limited to arrays, so they should go into the base library ...
/s/ Adam
Philipp