Re: Possible bug with the length operator

[Benoit Germain <bnt.germain@...>]

2011/4/1 HyperHacker <hyperhacker@gmail.com>

__newindex is called even if the value being set is nil. The problem
is that __newindex isn't called if the key already exists (presumably
for optimization). So you need to use __index and __newindex to proxy
all accesses to a hidden table somewhere so that you can catch those
nil assignments. Then you're free to handle "holes" however you like.

--
Sent from my toaster.

Ain't this why __killindex/__remindex/__delindex/__rmindex/whatever, called only when doing t[k] = nil, would be a good idea?
Proxying every access with __newindex, thus forcing to use __index too for regular access, is more costly that checking for __killindex when doing t[k] = nil.

It doesn't have to be called for every assignment, like __newindex would be in case you proxy everything inside a hidden table, only when k is non-nil and v is nil.
Are there real-life cases where some code would remove keys from tables so many times that checking for this metamethod would incur a significant cost?
There is one problem though: with userdata proxying, one has to decide wheter to call __newindex or __killindex when setting a key to nil... unless __killindex is specific to tables.


-- 
Benoit.