[whatwg] Web Storage: structured clones lead to ambiguity in detecting if a key is set w/ getItem()

On Wed, 23 Sep 2009 20:19:43 +0200, Brett Cannon <brett at python.org> wrote:

> Before the move to structured clones one could tell if a key was set
> by calling getItem() and seeing if it returned null (had to use === as
> someone could have called setItem() w/ null, but that would be coerced
> to a string for storage). But with the latest draft's switch to
> structured clones that test no longer clearly differentiates between
> whether the value returned by getItem() signifies that the key was not
> set, or the key was set with the value null.
>
> As written right now the only way to detect if a key was truly set is
> to iterate through all of them with 'length' and key(). Perhaps a
> contains() function that returns true/false based on whether the key
> is set is warranted? Otherwise you could do something like Python's
> get() method on dicts where an optional second argument is provided to
> getItem() which is returned only if the key is not set, allowing a
> user-provided object represent a key not existing w/ ===.
>

Yes, there is ambiguity in getItem() between the case of non existent key  
or the case or null key.
But does storing null keys adds any value, or relevant information ?

The User Agent could optimize by treating a setItem(key, null) as a  
removeItem() because getItem() would return in both cases null, and it  
would be an opportunity to spend less quota of the storage area. The only  
side effect of such optimization would be that setItem(key, null) would  
not produce a new key entry that could be read by key(index).

But back on the original issue, doing a setItem(key,null) is just  
redundant overhead that does not had any information, so the spec could  
just allow the harmless ambiguity to happen.
I personally would prefer setItem(key,null/undefined) to be treated as  
removeItem(key).

Received on Wednesday, 23 September 2009 13:31:30 UTC