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: Brett Cannon <brett@python.org>
Date: Wed, 23 Sep 2009 14:38:25 -0700
Message-ID: <bbaeab100909231438xc7550fw2c563a01a2d4d689@mail.gmail.com>
On Wed, Sep 23, 2009 at 14:28, Jo?o Eiras <joaoe at opera.com> wrote:
> On Wed, 23 Sep 2009 23:03:38 +0200, Erik Arvidsson
> <erik.arvidsson at gmail.com> wrote:
>
>> 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.
>>
>
> A containsKey or hasItem, preferably, would still not address the ambiguity
> issue.

It doesn't remove it, but it helps deal with it. You could use
hasItem()/containsKey()/whatever() in cases where you did receive null
from getItem() and you care if the key was actually set or not.

Otherwise the only other good solution is adding a singleton to the
Storage interface which getItem() returns when the key is not set.
Disallowing using 'undefined' or null as a value suddenly as a special
case just for Storage.setItem() when it comes to working with
structured clones.

But if people really want to go down that route I would swap from null
to undefined to better match JS semantics of representing when
something doesn't exist.

-Brett
Received on Wednesday, 23 September 2009 14:38:25 UTC

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