<div class="gmail_quote">On Wed, Sep 23, 2009 at 1:31 PM, Joćo Eiras <span dir="ltr"><<a href="mailto:joaoe@opera.com">joaoe@opera.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">On Wed, 23 Sep 2009 20:19:43 +0200, Brett Cannon <<a href="mailto:brett@python.org" target="_blank">brett@python.org</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Before the move to structured clones one could tell if a key was set<br>
by calling getItem() and seeing if it returned null (had to use === as<br>
someone could have called setItem() w/ null, but that would be coerced<br>
to a string for storage). But with the latest draft's switch to<br>
structured clones that test no longer clearly differentiates between<br>
whether the value returned by getItem() signifies that the key was not<br>
set, or the key was set with the value null.<br>
<br>
As written right now the only way to detect if a key was truly set is<br>
to iterate through all of them with 'length' and key(). Perhaps a<br>
contains() function that returns true/false based on whether the key<br>
is set is warranted? Otherwise you could do something like Python's<br>
get() method on dicts where an optional second argument is provided to<br>
getItem() which is returned only if the key is not set, allowing a<br>
user-provided object represent a key not existing w/ ===.<br>
<br>
</blockquote>
<br></div>
Yes, there is ambiguity in getItem() between the case of non existent key or the case or null key.<br>
But does storing null keys adds any value, or relevant information ?<br>
<br>
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).<br>


<br>
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.<br>
I personally would prefer setItem(key,null/undefined) to be treated as removeItem(key).<br>
</blockquote></div><br><div>IIRC, this is how it used to be.  If so, does anyone remember why this was changed?</div><div><br></div><div>Also, what about undefined?  It seems kind of weird that we'd let someone store undefined and not null.</div>