On May 20, 2008, at 2:00 PM, Ian Hickson wrote:
On Mon, 19 May 2008, Maciej Stachowiak wrote:
On May 19, 2008, at 4:54 PM, Robert O'Callahan wrote:
If "storage.keyName = 'value';" can create a new storage item
(persistently), won't authors expect "delete storage.keyName;" to
remove it (persistently), as a matter of consistency?
If overloading "delete" is too quirky or too hard to implement, then
it seems none of the other shorthands should be allowed either.
Many objects in the DOM implement custom name getters (for instance
NodeList) and a few even implement custom name setters
(CSSStyleDeclaration, at least the way it is done in WebKit) but no
one
has clamored for a custom deleter or expected delete to work "as a
matter of consistency" or been confused that "style.opacity = 0" is
allowed but "delete style.opacity" is not. So I would say the
available
evidence argues against your conclusions.
The difference is that "style.opacity = 0" doesn't remove "opacity"
from
the "style" object but "storage.removeItem('opacity')" _does_ remove
"opacity" from the "storage" object.
Yes, the analogy to storage.removeItem() would be
style.removeProperty(). You can't do "delete style.opacity" instead of
"style.removeProperty('opacity')" and as far as I can tell, no one has
ever asked to be able to use delete on style, or been especially
confused that they couldn't.
Originally, I wanted Storage objects to be indistinguishable from
Object
objects in JS, and native hash or collection objects in other
bindings.
Conceptually, that's what these objects are -- native name/value pair
collections that happen to be mapped to non-volatile storage (or
somewhat-
volatile storage, in the case of sessionStorage).
Normal objects don't fire DOM events when you change their properties
(I imagine the same may be true of native hash objects in at least
some languages), so the indistinguishability only goes so far.
I'd also like the "delete" operator to work on DOMStringMap (for the
dataset object -- calling 'delete' on that has the side-effect of
removing
the underlying attribute) and UndoManager (where the side-effect is to
remove the entry and renumber the following entries, so maybe that's
not
such a good idea after all), for what it's worth. If we want to decide
that we're not supporting this, we should decide that before
implementations of those come about.
Those both sound suboptimal to me. UndoManager because it remove more
than the one item, and DOMStringMap because (a) you can't delete from
NamedNodeMap to remove an attribute so it would be inconsistent and
(b) removing an attribute causes a mutation event to fire and thus
runs arbitrary code (creating the same problem of 'delete' running
arbitrary code as Storage).
For DOMStringMap, my intention was to not provide methods at all,
and only
provide the JS-native mechanisms.
A bold choice, but I would not recommend it as the sole available
mechanism.
Regards,
Maciej
