On 8/15/12 5:08 PM, Brendan Eich wrote:
Usually window.[standardized property name] is last -- this matters below.
I don't see how it matters at all, actually.
Firefox is affected by this problem (e.g., the result of the var
declaration is undefined)
Chrome is not affected by this problem because their var creation
algorithm checks the prototype chain for an existing property name
No, Chrome is not affected because their IDL bindings put inherited
attributes on the global object as "own" accessors.
It's not affected for both reasons, at least in the last version of
Chrome I tested.
That's true, but see above point about order of || terms.
Again, the order of the || terms doesn't matter. "X || undefined" and
"undefined || X" both evaluate to X as long as X is not falsy.
No. Rather, the erratum at
https://bugs.ecmascript.org/show_bug.cgi?id=78 was already fixed by
Mozilla, Google, Opera, and I believe IE and Apple.
It's not fixed by Apple as of the 2012-08-06 WebKit nightly.
It does seem to be fixed in Chrome dev (22.0.1229.6). It's not fixed in
Chrome beta (21.0.1180.79). We'll see if and when the fix makes it to a
final release, but in the meantime what's out there in users' hands
right now does not have the fix.
Also, WebIDL-reliant spec authors must be careful not to define get-only
accessors (readonly attributes) on the global object or interfaces from
which it inherits. This leads to the idea that the global object
defaults to [Replaceable] (which may be removed from WebIDL as explicit
qualifier syntax) and [Unforgeable] must be used selectively for some
few historic exceptions.
Note that there is a middle ground between [Replaceable] and
[Unforgeable], which is where most props on the global live right
now.... I suspect for web compat we may want to default all future
stuff to being [Replaceable] but grandfather in the existing
non-replaceable things.
-Boris
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
