[whatwg] WebIDL vs HTML5 storage changes
giecrilj at stegny.2a.pl
Tue May 20 11:35:48 PDT 2008
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.
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."
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.
about objects that might or might not change the behavior of the
"delete" operator. One reason i would find it very difficult is that
understand this one API, I would need to understand a vast corpus of
programming language goobery that is not at all covered in any
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!
More information about the whatwg