[whatwg] WebIDL vs HTML5 storage changes

[Kristof Zelechovski]

Suppose you successfully delete a property of an object that gets ultimately
persisted that object on the server using XMLHttpRequest with JSON.  Your
action of deleting the property is absolutely legal and it undoubtedly has
side effects.  How is it different from the local storage case, except that
it is persisted implicitly by the session manager?
In other words, deleting a property from local storage does not change
anything in persistent memory by itself; it is the session manager that
executes the change afterwards.  It is possible because the local storage
belongs to the global state.  The operator delete is not overloaded.
Chris

-----Original Message-----
From: whatwg-bounces at lists.whatwg.org
[mailto:whatwg-bounces at lists.whatwg.org] On Behalf Of Geoffrey Garen
Sent: Tuesday, May 20, 2008 12:19 AM
To: Brady Eidson
Cc: Maciej Stachowiak; WHATWG Mailing List
Subject: Re: [whatwg] WebIDL vs HTML5 storage changes

> My instinct is that if the community decides it is "just kind of  
> weird", then it is a useful shorthand that we wouldn't lose anything  
> from standardizing on.

It is *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.

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 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. 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. 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"). 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 :).

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!

Geoff