>>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
