 |
lua-l archive |
|
|
||
|
Am 17.03.2018 um 18:08 schrieb Coda Highland:
> On Sat, Mar 17, 2018 at 11:55 AM, Stephan Hennig <sh-list@posteo.net> wrote:
>> Am 17.03.2018 um 17:06 schrieb Stephan Hennig:
>>
>>> I tend to think tables with nil are constant size or grow only. So
>>> here's a stupid question:
>>>
>> What use-case is there to have nil in tables /and/ to be able to
>> delete (any) values from the same tables?>
> One realistic example: Imagine a cache table that holds the results of
> expensive function calls. The function can return nil, so you have to
> be able to store that, and you need to be able to remove entries in it
> as they become stale.
>
> Without the ability to delete keys distinctly from storing nil, you
> would have to use a singleton to act as a fake nil and then detect> that and replace it with a real nil at runtime. Possible, sure, but a
> bit ugly.
Or a second fall-back table containing a true value for all keys with a
nil value.
Anyway, when caching values you're pretty much into the metatable
business already. That is, this use-case has already a requirement of
the same complexity as the Lua-ish way of storing nil in tables via
metatables already provides. Nice example, but I don't see a pressing
need for a change in the language (undef) from this one. (I do see a
need for easier handling of nil in tables, though. But that need can be
satisfied with more metatable mechanisms as has been proposed by others
already.)
> Another realistic example: For performance reasons, you're trying to
> reuse tables as much as you can. If you need to be able to distinguish
> between a nil value and an absent key, then you HAVE to be able to
> properly delete keys if you're going to reuse tables.
A more tough one to discuss away. :-)
For the simple case of finally emptying a table containing nils in
preparation of reuse, a new function table.empty() can be provided that
does exactly that.
If single keys had to be removed during lifetime of a table, this
use-case has the following requirements
a) performance (no metatables if possible),
b) storing nil in tables,
This certainly required something like undef. It is not quite a common
use-case, though, I guess.
Thanks for the examples, Coda! May be obvious, but I'd just feel better
with tables with nils, but without undef.
Best regards,
Stephan Hennig