Clarification on function default param values

Andrea Giammarchi andrea.giammarchi at gmail.com
Tue Oct 1 13:26:22 PDT 2013


I need to read everything Brendan suggested but if anyone would be so kind
to refresh my memories on this arrow function I'd appreciate that. I don't
need much more than yes/no as answer, thanks.

  1. `var o = {method: () => this};` will o.method() return o ? (I guess
nope)

Considering the following code:

```javascript
var Proto = (function(){
  this.method = () => this;
  return this.constructor;
}.bind(function Proto() {}.prototype));
```
  2. will it work as expected per each `new Proto` object ? (I guess nope,
everything referred to Proto.prototype)

Considering the following code:

```javascript
var o = {i: 0};

(function(O){

  O.fatMethod = (i) => i + this.i;
  O.justMethod = function (i) {
    return i + O.i;
  };

}.bind(o,O));
```

  3. will the `fatMethod` be ideally/theoretically/technically faster to
execute once made hot through JIT capable engines (or made preventively hot
since immutable in such form) ?

My bonus, humble, honest, and final question would be:

  4. what kind of problem is this fat arrow feature trying to solve
exactly, if it cannot be used for classes, direct methods assignment, but
only for some runtime event assignment instead of using bind and still
being unable to remove that listener later on ?

Thanks a lot in advance for any refreshing and/or enlightening answer, it's
actually a while I am wondering this stuff.

Best Regards






On Tue, Oct 1, 2013 at 11:59 AM, Mark S. Miller <erights at google.com> wrote:

> I agree that the discussions as I remember them do not go into this level
> of detail. Thanks for being so explicit about precise choices.
>
> However, I do recall that the consensus we had was enough to rule out #3,
> or indeed any solution where arrow functions have their own arguments
> object. And even if I recall wrongly, I do think arrow functions should not
> get their own arguments object -- that's too surprising from an
> arrow-function-as-smalltalk-block-like perspective.
>
> #7 can be explained in a memorable way:
>
> Generally variables are brought into scope by an explicitly appearing
> defining occurrence. Two exceptions are the "function" brings into scope
> both "this" and "arguments". These remain in scope until shadowed by a
> nested "function" or by an explicit definition. Note that "this" can never
> be explicitly defined, and "arguments" can only be explicitly defined in
> non-strict code.
>
> As of ES6, a variety of other function-defining constructs, like
> "function", implicitly bring into scope a new "this" and "argument".
> Arrow-functions are not one of these. Within an arrow function, both "this"
> and "arguments" are lexically captured from the enclosing context.
>
>
>
>
> On Tue, Oct 1, 2013 at 11:19 AM, Erik Arvidsson <erik.arvidsson at gmail.com>wrote:
>
>> 3 and 7 both seems good. Personally I prefer #7 but I'm worried that
>> it might be too surprising that arguments refers to the outer
>> function.
>>
>> On Tue, Oct 1, 2013 at 11:11 AM, Allen Wirfs-Brock
>> <allen at wirfs-brock.com> wrote:
>> >
>> > On Oct 1, 2013, at 12:03 AM, André Bargull wrote:
>> >
>> >> Brandon Benvie <mailto:bbenvie at mozilla.com>
>> >> September 30, 2013 8:48 PM
>> >> I'm actually now really curious what the following does:
>> >>
>> >> ```
>> >> function foo(x, y = (() => { arguments[0] = "foo"; return "bar" })()) {
>> >>   return [x, y];
>> >> }
>> >
>> > Easy: arguments is an early error in the body of an arrow.
>> >
>> > http://wiki.ecmascript.org/doku.php?id=harmony:arrow_function_syntax
>> >
>> > /be
>> >
>> >
>> > This restriction is  not specified in the rev19 draft. Currently arrow
>> > functions don't have an own `arguments` binding, but instead access the
>> > outer functions `arguments` object, similar to `this`. Disallowing the
>> > identifier "arguments" in PrimaryExpressions also should imply
>> disallowing
>> > "arguments" as a BindingIdentifier, which shifts arrow functions again
>> into
>> > "almost strict-mode".
>> >
>> > - André
>> >
>> >
>> > The restriction we want and how to enforce it is not all that clear.
>> >
>> > We don't really want to have an "almost strict" mode for the body of
>> arrow
>> > functions, if that was going to be the case I think it would be much
>> better
>> > to simply say that arrow functions are always strict.
>> >
>> > The spec. currently applies the static semantics of strict mode formal
>> > parameters (no duplicate names, can't name a parameter 'eval' or
>> > 'arguments') to arrow function formal parameters, but in all other ways
>> both
>> > the formal parameter list (think default value expressions) and the
>> arrow
>> > function body follow the strictness of the surrounding code.
>> >
>> > that means things like the following are valid in non-strict arrow
>> > functions:
>> >
>> > () =>  {function arguments() {}; return arguments}
>> > () => {let arguments =5; ...}
>> >
>> > So we can't just statically disallow 'arguments' references in a
>> ConciseBodu
>> >
>> > Also, we have to have consistent behavior for an
>> >   eval('arguments')
>> > that appears in a ConciseBody.
>> >
>> > Here are possible reasonable alternatives for handling arguments in
>> arrow
>> > functions:
>> >
>> > 1) nothing special, same rules as a FunctionExpression. An arguments
>> object
>> > is available and strict/non-strict distinctions apply both statically
>> and
>> > dynamically.
>> >
>> > 2) nothing special, but strict arguments object.  Just like #1 except it
>> > always has a strict mode arguments object (no joining of augments
>> elements
>> > and formal parameters
>> >
>> > 3) #2, plus strict mode parameter naming restrictions are also applied
>> (no
>> > duplicates, can't use 'eval' or 'arguments' as parameter names)
>> >
>> > 4) no-arguments objects with shadowing, 'arguments' binds to undefined.
>> > Arrow functions do not have an arguments objects but they have an
>> implicit
>> > constant binding of 'arguments' in their parameter scope whose value is
>> > undefined.  References to 'arguments' in the body evaluate to undefined.
>> > (unless, non-strict and there are explicit declarations of the name
>> > 'arguments');
>> >
>> > 5) no-arguments objects with shadowing, 'arguments' is in temporal dead
>> > zone.  Arrow functions do not have an arguments objects but they have an
>> > implicit binding of 'arguments' in their parameter scope that is never
>> > marked as initialized.  References to 'arguments' in the body throw
>> because
>> > they are temporal dead zone references. (unless, non-strict and there
>> are
>> > explicit declarations of the name 'arguments' that shadow the parameter
>> > level binding);
>> >
>> > 6) nothing special, but no arguments object, normal lexical scoping.
>> Like #1
>> > except that there is no arguments object or local binding of
>> 'arguments'.
>> > References to arguments resolve via the enclosing scope.
>> >
>> > 7) strict mode name restrictions, but no arguments object, normal
>> lexical
>> > scoping. Like #3 except that there is no arguments object or local
>> binding
>> > of 'arguments'.  References to arguments resolve via the enclosing
>> scope.
>> >
>> > The rev19 spec. current has approximately #7 but there isn't anything
>> final
>> > about that.  It sounds to me like some think either #3 or #4 is the
>> plan of
>> > record although I don't think we've talked about it at a TC39 meeting
>> that
>> > this level of detail.
>> >
>> > I think #3 would be a good solution. So is #7.
>> >
>> > #3 probably would seem reasonable to JS programmers. #7 probably is what
>> > lexical scoping heads would expect. #4 or #5 is a completely new
>> semantics
>> > that I don't think anyone expects.
>> >
>> > Allen
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > es-discuss mailing list
>> > es-discuss at mozilla.org
>> > https://mail.mozilla.org/listinfo/es-discuss
>> >
>>
>>
>>
>> --
>> erik
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
>
> --
>     Cheers,
>     --MarkM
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20131001/1b962bb5/attachment.html>


More information about the es-discuss mailing list