- From: Brady Eidson <beidson@apple.com>
- Date: Mon, 19 May 2008 16:52:35 -0700
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
Received on Monday, 19 May 2008 16:52:35 UTC