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

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/ ===.

And since I just subscribed to the mailing list, I was wondering if
the whole workers/localStorage discussion ended or not, as I can
provide a (potentially minor) real-world use-case for sharing access
between the page and worker if people want to hear it (in a new email
of course).

-Brett

Received on Wednesday, 23 September 2009 11:19:43 UTC