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

On Wed, Sep 23, 2009 at 1:19 PM, 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/ ===.
>
> 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).

The second method (optional second argument) is definitely the correct
one.  Common Lisp deals with similar issues by *returning* a second
value which is a boolean reflecting whether the key was in the hash
(and was simply set to the default value) or was missing (and thus the
default value was returned).  However, multiple return values isn't a
pattern used by most languages, so a second argument that switches the
function into returning the was-it-there bool is correct.

~TJ

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