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- > international.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- > addrestrictedfunctionproperties > -- > "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
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
