[whatwg] WebIDL vs HTML5 storage changes

[Brady Eidson]

Pardon the length of my reply, I probably put more effort into it than  
I should've...  ;)

I'm unsure if you have the proper background with the Storage  
interface that is in question here.  I'm guessing that the reason that  
Firefox 2 and IE8 support the "modified" behavior of delete for  
Storage items is because the "way of thinking about Storage items"  
we're trying to get across meets most of the expectations of  
manipulating properties that you lay out below.

On May 19, 2008, at 3:18 PM, Geoffrey Garen wrote:
> very* weird, and therefore not a "useful shorthand."
>
> In JavaScript, "delete" means "remove this property / interface from  
> this JavaScript object." I can't think of any context in which it  
> means anything else.

The spec makes it clear that storage items and properties on the  
Storage object are interchangeable.
`storage.foo = "bar"` happens to be equivalent to  
`storage.setItem("foo", "bar")`, but is also no different from  
`someRandomObject.foo = "bar"` as far as keeping a collection of  
properties on an object.

This also applies for enumeration, etc.

Equivalently and more relevant to the discussion, `delete storage.foo`  
happens to be equivalent to `storage.removeItem("foo")`, but is also  
*little* different from `delete someRandomObject.foo`

> For example, "delete node.parentNode" attempts to remove the  
> "parentNode" property from "node". It does not remove "parentNode"  
> from the document or anything like that.
> "delete window" attempts to remove the "window" property from the  
> global object. It does not close the window or anything like that.

In the SessionStorage case, this applies with zero caveats.  In the  
LocalStorage case, it applies with the caveat that "all of the  
properties you set on this object will still be on this object's  
analog the next time you restart the browser and come back to this page"

And that's the really weird thing, I think - window.localStorage can  
be thought of exactly like every other javascript object, except it is  
not temporary.  It gets created once and maintains it's state over  
browser launches.  We're already breaking the javascript-assumption- 
mold when you get into that mindset.

Neither IE8 or FFX have implemented LocalStorage in a release yet, so  
perhaps they would not support the syntax for LocalStorage, and only  
support it for SessionStorage.  Of course that would be even weirder,  
having 2 concrete implementations of the same interface have "API  
incompatibilities"

> In other words, you can be certain that "delete" is a simple  
> operation with a consistent side-effect.
> As a JavaScript programmer, I would find it very difficult to reason  
> about objects that might or might not change the behavior of the  
> "delete" operator.

Is the behavior of the delete operator "remove the property from the  
object" or is it actually "remove the property from the object with  
zero other detectable side effects"?

> One reason i would find it very difficult is that operator  
> overloading does not exist in JavaScript at all, so to understand  
> this one API, I would need to understand a vast corpus of  
> programming language goobery that is not at all covered in any  
> JavaScript manual.

I think this is a pretty shameful exaggeration ;)

> Another reason I would find it very difficult is that the overloaded  
> meaning of "delete" here ("remove persistent storage from disk") is  
> far afield from the original meaning ("remove interface from  
> temporary object in memory").

The overloaded meaning of "delete" here is "remove interface from  
temporary object in memory, as well as the persistent record of its  
existence."  Still different from the original meaning, but not "far  
afield" different.

> To give you an analogy, even in C++, where you're allowed to  
> overload operator delete, if you overloaded operator delete to mean  
> "do not free this object's memory, but do delete the file it  
> references from the file system", well, let's just say that your  
> patch would not pass code review with any of your four reviewers :).

But if you overloaded the delete operator to free the object's memory  
*and* delete its referenced files from the file system, you'd be using  
the operator overloading in its intended capacity.

> I am not sure if any JS decoration or collection libraries depend on  
> the canonical behavior of operator delete, but if they do, I would  
> hate for them all to have to ship with the asterisk, "BEWARE: do NOT  
> use this decoration / collection library with that one weird DOM  
> object that interprets 'delete' to mean 'remove important data from  
> the user's disk'". Oy!

At the same time, why not be concerned that such a collection library  
happens to expose the exact same API interface that the Storage object  
exposes, and now that library should carry the same warning saying  
"BEWARE: do NOT use this collection library with that one weird DOM  
object that interprets 'clear()' to mean 'remove important data from  
the user's disk'?

The fact that we're giving scripts the ability to directly manipulate  
data on the users disk is already a jump-off-a-bridge as far as I'm  
concerned.  Shouldn't a script writer using LocalStorage use due  
diligence to make sure his data is actually safe as expected?

****

A few final thoughts...

Despite appearances to the contrary, I'm not strongly in favor of  
keeping this syntax or standardizing it.  I'm just not nearly as blown  
away by how weird this seems, and can easily spot the motivations  
FFX2+ and IE8 had for adding this custom behavior.

I suppose another important bit of historical information is that when  
FFX originally implementing this, the world of DOM storage was quite  
different - there was SessionStorage and there was GlobalStorage.   
SessionStorage doesn't have any of this nasty "persistence"  
requirement that fuels this discussion, and GlobalStorage wasn't  
exactly the same interface and therefore doesn't even suffer the  
`delete` operator problem.

My big concern is that there is no good outcome here without the  
standard stepping in to specify, and even then there might not be a  
good outcome.  Possible scenarios:

1-The spec doesn't add the delete behavior.  Firefox2 and IE8 both  
drop it, breaking scripts written in the past, but allowing for a  
clear future.

2-The spec doesn't add the delete behavior.  Firefox2 and IE8 do NOT  
drop it from SessionStorage, to not break past scripts.  No new  
browser implements it.  New compatibility problem introduced to the  
web, meaning a minor failure in the whole intention of the spec.

3-The spec doesn't add the delete behavior.  Firefox2 and IE8 *add* it  
to their LocalStorage implementations, possibly bringing up the demons  
that Geoff suggests.   New compatibility problem introduced to the  
web, even more severe than scenario #2, meaning an even greater  
failure in the whole intention of the spec.

4-The spec adds it for SessionStorage only.  None of the above  
concerns apply because it's temporary, anyway.  IE8 and FFX hold the  
course, other browsers add it for SessionStorage as well.  All  
browsers act the same, which is great.  But the bizarre  
incompatibility between SessionStorage and LocalStorage, which are  
supposed to have identical interfaces, rears its ugly head on the web.

5-The spec adds it for both Session and LocalStorage.  IE8 and FFX  
adopt.  Other browsers adopt.  There's a standard that everyone  
follows, no past scripts are broken, and there's compatibility going  
forward.  It is possible that the nonstandard delete behavior will  
cause a problem with someone's assumptions about the temporary nature  
of objects and properties.

Of the above scenarios, none are perfect.  If we just ignore the  
issue, though, and WebKit revert's it's change which added the  
property, then #2 or #3 are the outcome, and they are my *least*  
favorite options.  :)

~Brady