- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 20 May 2008 14:17:35 -0700
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
Received on Tuesday, 20 May 2008 14:17:35 UTC