I am in agreement with Angus on this one. If there is no skinny arrow, hard |this| binding should not be part of the spec. Fat arrow functions should default to lexical |this|, but if there is no skinny arrow, it should not be a hard binding and call/apply should be allowed, as well as bind,
On Sat, Apr 21, 2012 at 1:02 PM, Angus Croll <[email protected]> wrote: > >>4) Should it be a dynamic error to try to use apply/call to set the this > binding of an arrow function. > > >>Cons > >>To much existing code speculatively binding the this value when invoking > a function. > > >>I propose that call/apply simply ignore the this value when invoked on > an arrow function. > > What is the pro of ignoring explicit |this| binding instructions in > call/apply on arrow functions? > What is the con of continuing to allow legacy code to speculatively bind > the |this| value when invoking any function? > Why is it so important that fat arrows do a hard |this| binding? > > > > On Fri, Apr 20, 2012 at 4:22 PM, Allen Wirfs-Brock > <[email protected]>wrote: > >> Here are a few design alternates that have come up as I work the >> specification draft for arrow functions >> >> 1) Always strict? Should all arrow functions be considered strict >> functions? >> >> Pros >> It's a new syntactic form, so it is it easy to make it be an implicit >> opt-in to strict mode. >> We generally want to encourage use of strict mode. >> If not, there would no way to to make an expression-bodied arrow function >> a strict function (other than by nesting it in strict code) >> Always strict eliminates the need for some of the arrow special case >> alternatives discussed below >> >> Cons >> We shouldn't be trying to force use of strict mode. >> Programmers who don't know about strict mode may get confused by the >> application of strict mode semantics to arrow functions >> It would create a refactoring hazard for non-strict code. >> >> 2) Redeclaring eval in non-strict arrow functions >> >> Should strict mode eval declaration/assignment restrictions be be imposed >> upon non-strict arrow functions? >> >> I propose disallow binding eval or assigning to it all arrow functions >> >> 3) Declaring arguments as a formal parameter, or local binding in a >> non-strict arrow function >> >> The wiki proposal says arguments can't be used as an expression primary >> but doesn't say anything about declarations >> >> I propose binding or assigning or referencing arguments within a arrow >> function. >> >> 4) Should it be a dynamic error to try to use apply/call to set the this >> binding of an arrow function. >> >> Cons >> To much existing code speculatively binding the this value when invoking >> a function. >> >> I propose that call/apply simply ignore the this value when invoked on an >> arrow function. >> >> 5) Should arrow functions define the [[HasInstance]] internal method. >> In other words should should: >> obj instanceof () => {} >> do? >> If it doesn't have [[HasInstance]] then instanceof would throw a type >> error. Alternatively, it could have a [[HasInstance]] that always returns >> false. >> We have already decided that arrow functions don't have a [[Construct]] >> internal method nor a prototype property. >> >> I propose that arrow functions do not have a [[HasInstance]] internal >> method. >> >> 6) Do arrow functions need to have per instance "caller" and "arguments" >> poison pill properties? >> >> I propose no, because they are a new feature. But we can include a NOTE >> warning against providing their non-standard legacy implementation. >> >> 7)All of the above questions also apply to functions defined using >> concise method syntax in object literals or classes. Should the same >> answers apply to them? >> _______________________________________________ >> 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 > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
