Ugh!! It's a trap! (In the Star Wars sense, not the proxy sense.) So if all my code is in strict mode, and I get a non-strict code function to shadow as Tom and I were talking about in another thread... how do I even test for that if my code is either consistently strict or consistently non-strict?
On Mon, Sep 5, 2016 at 6:21 PM, Mark S. Miller <[email protected]> wrote: > Besides those two, the only other reference to > AddRestrictedFunctionProperties is <http://www.ecma- > international.org/ecma-262/7.0/#sec-createintrinsics> step 12: > > 12. Perform AddRestrictedFunctionProperties > <http://www.ecma-international.org/ecma-262/7.0/#sec-addrestrictedfunctionproperties> > (funcProto, realmRec). > > So .caller and .arguments must now exist as poisoned on (the intrinsic > normally bound to) Function.prototype . So, besides Function.prototype, > they may only appear on old-style sloppy functions; nowhere else. > > > > On Mon, Sep 5, 2016 at 6:09 PM, Caitlin Potter <[email protected]> > wrote: > >> The part that matters here is in annex B: http://www.ecma-internation >> al.org/ecma-262/7.0/#sec-forbidden-extensions >> >> This forbids functions in strict code from having own properties "caller" >> or "arguments". Newer function kinds have these restrictions in sloppy mode. >> >> AddRestricted... adds the accessor which makes getting/setting "caller" >> or "arguments" throw, but is per spec only performed on intrinsics (like >> %FunctionPrototype%). >> >> So unfortunately, this is something your membrane would need to be aware >> of and work around. Mozilla's approach violates ECMAScript's forbidden >> extensions and can't be considered "correct" >> > > This result by itself does not demonstrate that Mozilla or v8 are either > conformant or non-conformant. By the spec, A must not have its own .caller > and .arguments -- it must only inherit these from Function.prototype. B, > being sloppy, may or may not. > > > >> >> >> Sent from my iPhone >> On Sep 5, 2016, at 8:54 PM, Alex Vincent <[email protected]> wrote: >> >> <script> >> "use strict" >> function A() {} >> </script> >> <script> >> function B() {} >> </script> >> <script> >> window.onload = function() { >> let a = Reflect.ownKeys(A); >> let b = Reflect.ownKeys(B); >> document.getElementById("output").value = (a.includes("arguments") >> === b.includes("arguments")); >> } >> </script> >> >> Mozilla Firefox reports true. Google Chrome and node.js report false. >> Which one is correct? >> >> I looked through Mozilla's Bugzilla, Google Chrome's Monorail, and the >> ES7 spec to try figuring this out. The closest I could get was section >> 9.2.7 of the ES7 spec. [1] >> >> Right now I have an inadvertent mix of strict code / non-strict code in >> my membrane, and this difference is causing my most recent patch to fail >> tests in nodejs and Google Chrome, and to pass in Mozilla Firefox. In >> Chrome and nodejs, I get: >> >> TypeError: 'ownKeys' on proxy: trap result did not include 'arguments' >> >> If it turns out Google & nodejs are correct, this could be an issue going >> forward: I can't control whether my membrane library's users are running >> strict mode code or not... likewise, I don't know if my code should be >> consistently strict mode or consistently non-strict. (I feel that a mix is >> not good, except for finding bugs like this...) >> >> My apologies for treating this list as a help forum, but I'm just not >> sure where else to go... >> >> [1] http://www.ecma-international.org/ecma-262/7.0/#sec-addrestr >> ictedfunctionproperties >> -- >> "The first step in confirming there is a bug in someone else's work is >> confirming there are no bugs in your own." >> -- Alexander J. Vincent, June 30, 2001 >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > > -- > Cheers, > --MarkM > -- "The first step in confirming there is a bug in someone else's work is confirming there are no bugs in your own." -- Alexander J. Vincent, June 30, 2001
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
