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

On Wed, Sep 23, 2009 at 11:30 AM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:

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

I would say it's far from "definitely the correct" method.  I can see use
cases where both the default case and a containsItem() function would be
useful.  Why not add both?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090923/40d3d7ba/attachment.htm>

Received on Wednesday, 23 September 2009 13:04:01 UTC