Re: The Clear Table Saga

["Peter Hill" <corwin@...>]

Wim Couwenberg:
> On second (or third?) thought, I'd suggest a slightly
> altered version of the C implementation of zap_table:

Wim Couwenberg:
> Aaahhh...  That seemed like a good idea but it is in fact *terrible*!

> The reason for the huge difference is (IMHO) simple: since setting a field
> to nil does not remove it from the table it will consequently take longer
> and longer to find the first non-nil valued field if we start from scratch
> each time!

What I'd like to see is tables storing (internally & invisibly) an offset to
the first non-nil key. That way starting 'next()' from scratch each time
will not be prohibitive.

I'd prefer this to just puting a warning in the manual entry for 'next()'
since it would hide the internal implementation which otherwise becomes
painfully clear when one tries Wim's 'third thought' version.


This also means that the preferred way to clear a table becomes using
'next(table,nil)' each time, since it is a use of 'next()' that is robust
against a future change to table implementation that might allow a table to
change size upon a key deletion (which it currently does not).

*cheers*
Peter Hill

PS:
The currently implementation of tables that doesn't allow shrinking with key
deletion might be handy BUT it requires the users of this otherwise rather
high level programming language to have intimate knowledge of table memory
handling. IE, it requires a user to manually add a dummy element to a table
to reclaim table memory after a large number of key deletions, which just
makes me *SHUDDER* all over.