[whatwg] Overriding functions in DOM Storage

What's special here is that everything set with the implicit getters/setters
is supposed to be turned into a string.  So yes this does seem somewhat
unique.

And yes, "there isn't good interop right now across the board"...but that's
one of the reasons the HTML 5 spec + WhatWG exist...right?  :-)

I think it's important to decide which behavior makes the most sense and
standardize on it.  The way things are now is pretty useless to eveyone.

J

On Tue, May 26, 2009 at 8:07 PM, Aaron Boodman <aa at google.com> wrote:

> 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
> >>
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090526/cfe023df/attachment.htm>

Received on Tuesday, 26 May 2009 20:17:32 UTC