W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2009

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

From: Jeremy Orlow <jorlow@chromium.org>
Date: Wed, 23 Sep 2009 13:40:08 -0700
Message-ID: <5dd9e5c50909231340i783689c9x3d5ca2424c997239@mail.gmail.com>
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090923/6337b2e9/attachment.htm>
Received on Wednesday, 23 September 2009 13:40:08 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:52 UTC