W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2009

[whatwg] Overriding functions in DOM Storage

From: Aaron Boodman <aa@google.com>
Date: Tue, 26 May 2009 20:07:53 -0700
Message-ID: <278fd46c0905262007k7663318cr7cc8d4555a2312bf@mail.gmail.com>
This isn't a localstorage specific question, this is a general
question about overriding methods on any host object.

The comments about shooting yourself in the foot are good points, but
the same exact thing is possible on every single API in the entire
environment. It doesn't make sense to worry about them wrt local
storage, specifically.

FWIW, I think that Safari's behavior is "correct" (a bit weird, but
correct). But this is an area where there isn't good interop right now
across the board.

- a

On Tue, May 26, 2009 at 7:44 PM, Jeremy Orlow <jorlow at google.com> wrote:
> No one else (especially from Mozilla or Microsoft)?? I was hoping to get a
> consensus here (and maybe even things spelled out more clearly in the spec),
> so that all the implementations could be headed in the same direction.? :-)
>
>
> On Fri, May 22, 2009 at 8:03 PM, Maciej Stachowiak <mjs at apple.com> wrote:
>>
>> On May 22, 2009, at 5:41 PM, Jeremy Orlow wrote:
>>
>>> What is the behavior of the following supposed to be?
>>>
>>> window.sessionStorage.removeItem = function(x) { alert("Wait, this
>>> works?"); };
>>> window.sessionStorage.removeItem('blah');
>>> alert(typeof window.sessionStorage.removeItem);
>>>
>>> Safari shows 2 alerts, and the second one says 'function'.
>>> IE8 says "object doesn't support this property or method" if line 2 isn't
>>> commented out. ?It returns type string when it is.
>>> Mozilla also won't run if line 2 is there, but it returns type object for
>>> line 3.
>>>
>>> It seems to me that if IE8's behavior is correct, those parameters should
>>> be marked as read-only since overriding them could only be used to shoot
>>> yourself in the foot.
>>>
>>> If Safari's implementation is correct (and it's good for the
>>> implementations to be overridable), then I believe there needs to be some
>>> safe way to make .clear() usable again. ?(Otherwise, once you override
>>> removeItem() and clear(), there's not really any way to recover.) ?The spec
>>> would also need to make it clear that removeItem, setItem, etc are special
>>> and should not be serialized to disk.
>>>
>>> Apologies if this is clear in the spec and I somehow missed it. ?But, if
>>> not, I think a clarification might be necessary.
>>
>> DOM methods are normally overridable. That would make the Safari behavior
>> correct. If we want the behavior to be different in this case, then the spec
>> should spell that out. Perhaps part of the issue here is that the definition
>> of the [NameSetter] extended attribute in Web IDL doesn't make clear whether
>> or not name setter behavior takes precedence over setting existing
>> predefined attributes or methods.
>>
>> Regards,
>> Maciej
>>
>
>
Received on Tuesday, 26 May 2009 20:07:53 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:49 UTC