A DOM use case that can't be emulated with direct proxies
Mark S. Miller
erights at google.com
Fri Dec 14 11:07:31 PST 2012
On Fri, Dec 14, 2012 at 10:19 AM, Brendan Eich <brendan at mozilla.com> wrote:
> David Bruant wrote:
>> Le 14/12/2012 08:25, Brendan Eich a écrit :
>>> window.location can be set by assignment to navigate to a new URL.
>> location is [Unforgeable, PutForward], so it should be reflected as a
>> non-configurable getter+setter according to WebIDL.
> That would be correct -- and nice, I agree.
>>> Yet it appears in Chrome, Firefox, Opera, and Safari to be a writable
>>> data property.
>> oh, web browsers and standards...
>> There is indeed a pretty violent mismatch between WebIDL and reality, I
>> guess. Specifically because of the behavior you're describing (assigning
>> window.location having a behavior), location ought to be an accessor.
>> What was the rationale that motivated all these browsers to go for data
>> property? Is it still time to change this behavior?
> Let's not make the standards-are-prior-to-implementations mistake. All this
> came from Netscape 2, JS1. It got cloned by IE and other browsers. It
> mutated and was not standardized until a decade later, in HTML5 and then
> DOM4 -- and WebIDL is an even later (still not REC, it's in CR if I recall
> correctly) standard.
> Nevertheless, since ES5-standard reflection is new, I doubt anyone cares
> that location appears to be a data property. It should be an accessor. But
> it needs to be non-configurable, so we still have a problem -- or do we?
AFAICT, a non-configurable accessor fits all the constraints.
More information about the es-discuss