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

[Erik Arvidsson]

What are the arguments against adding a containsKey method? This would
map consistently to the in operator and hasOwnProperty in ES5.
object.containsKey(name) would be mapped to [[GetOwnProperty]](object,
name) !== undefined in ES5 meta language. That seems most consistent
to existing APIs.

On Wed, Sep 23, 2009 at 13:40, Jeremy Orlow <jorlow at chromium.org> wrote:
> On Wed, Sep 23, 2009 at 1:31 PM, João Eiras <joaoe at opera.com> wrote:
>>
>> 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).
>
> IIRC, this is how it used to be.  If so, does anyone remember why this was
> changed?
> Also, what about undefined?  It seems kind of weird that we'd let someone
> store undefined and not null.



-- 
erik