- From: Jeff Walden <jwalden+es@MIT.EDU>
- Date: Thu, 07 Jul 2011 13:17:33 -0700
- To: Luke Hoban <lukeh@microsoft.com>
- CC: "Mark S. Miller" <erights@google.com>, Allen Wirfs-Brock <allen@wirfs-brock.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, "es5-discuss@mozilla.org" <es5-discuss@mozilla.org>
On 07/07/2011 10:33 AM, Luke Hoban wrote: > That interpretation implies that ES5 intentionally diverged from the behaviour that has been standard in all major browsers (until some starting changing recently) as far as I can tell. Has there been previous discussion of the compatibility implications? Yes, ES5 intentionally diverged. I imagine there was some compatibility discussion at the time, although I don't immediately remember it. Firefox, since making the change, has had no compatibility problems reported for it. (Although I should note that people sometimes called __defineGetter__ and __defineSetter__ unqualified, so those methods do still coerce null/undefined this to a global object. Since IE never had those, you don't have that problem to consider.) Well, there was one compatibility problem, from someone writing a jobs site of some sort, that this code no longer worked (brace yourself [pun intended] [meta-pun?]): ([][(![]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]+(!![]+[])[+[]]][([][(![]+[])[+[]]+(![]+[]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(![]+[])[+!+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[!+[]+!+[]]]()+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+([][(![]+[])[!+[]+!+[]+!+[]]+(!![]+[][(![]+[])[+[]]+(![]+[]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]])[+!+[]+[+[]]]+(!![]+[])[+!+[]]+(!![]+[])[+[]]][([][(![]+[])[+[]]+(![]+[]+[][[]])[+!+[]+[+[]]]+(![]+[])[!+[]+!+[]]+(!![]+[])[+[]]+(!![]+[])[!+[]+!+[]+!+[]]+(!![]+[])[+!+[]]]+[])[!+[]+!+[]+!+[]]+(![]+[])[+!+[]]+(![]+[])[!+[]+!+[]]+(![]+[])[!+[]+!+[]]]()+[ ])[!+[]+!+[]] That mess called a method with undefined as this, so with ES5 semantics it started throwing. But other than that report, which we rightly chose to treat as unimportant, it presented no issues. > As far as I understand, with multiple globals, the web-compatible behaviour is to pass the caller-side global. This is debatable. Half a year of translating undefined/null to the function's global produced only a single bug report. If that were the proper bar to change, Firefox would still accept trailing commas, leading zeroes, and tab characters in strings in JSON (changed in 4/5/5 respectively). I continue to believe that is the correct approach when multiple globals are standardized. Translating to the caller-side global would mean that |f()| and |f.call(undefined)| are no longer identical, if |f| is a non-strict function from another global. It would also be somewhat inconsistent with the "imAwesome" example Oliver mentioned in his response, at the very least to the eye of someone not intricately familiar with the inner workings of ECMAScript. Jeff
Received on Friday, 8 July 2011 13:40:30 UTC