Discuss
  • Function declarations with lexical `this`?

Function declarations with lexical `this`?

# Axel Rauschmayer (11 years ago)

Sorry for bringing this point up, again. It is a minor point, but details matter if ECMAScript 6 is supposed to feel consistent.

In general, I like how ECMAScript 6 has evolved functions. Before, functions played three roles:

  1. Constructor
  2. Method
  3. Non-method function (where you want lexical this)

In ES6, we have classes for #1 and method definitions for #2 (in both object literals and class literals). Furthermore, arrow functions replace function expressions and have lexical this. What is missing is a function declaration with lexical this.

What’s the best way to solve this and to eliminate the pitfall of dynamic this (at least for beginners)? Tell people to const-bind arrow functions? We’d lose hoisting, though. I also wouldn’t want to lose the symmetry function declaration/generator declaration and method definition/generator method definition.

IMO, we need a consistent story for ES6 in this area.

Axel

# Mark S. Miller (11 years ago)

On Mon, Jun 24, 2013 at 4:46 PM, Axel Rauschmayer <axel at rauschma.de> wrote:

Sorry for bringing this point up, again. It is a minor point, but details matter if ECMAScript 6 is supposed to feel consistent.

In general, I like how ECMAScript 6 has evolved functions. Before, functions played three roles:

  1. Constructor
  2. Method
  3. Non-method function (where you want lexical this)

In ES6, we have classes for #1 and method definitions for #2 (in both object literals and class literals). Furthermore, arrow functions replace function expressions and have lexical this. What is missing is a function declaration with lexical this.

What’s the best way to solve this and to eliminate the pitfall of dynamic this (at least for beginners)? Tell people to const-bind arrow functions?

IMO, yes.

We’d lose hoisting, though.

yes. I don't think this will actually be a problem in practice.

I also wouldn’t want to lose the symmetry function declaration/generator declaration and method definition/generator method definition.

I do sometimes wish there was a natural place to put a "*" on an arrow function, and sometimes I don't wish it. In any case, it's not gonna happen in ES6.

IMO, we need a consistent story for ES6 in this area.

const foo = (a,b) => a+b;

That's as consistent as it is likely to get.

# Dmitry Soshnikov (11 years ago)

On Mon, Jun 24, 2013 at 5:00 PM, Mark S. Miller <erights at google.com> wrote:

On Mon, Jun 24, 2013 at 4:46 PM, Axel Rauschmayer <axel at rauschma.de>wrote:

Sorry for bringing this point up, again. It is a minor point, but details matter if ECMAScript 6 is supposed to feel consistent.

In general, I like how ECMAScript 6 has evolved functions. Before, functions played three roles:

  1. Constructor
  2. Method
  3. Non-method function (where you want lexical this)

In ES6, we have classes for #1 and method definitions for #2 (in both object literals and class literals). Furthermore, arrow functions replace function expressions and have lexical this. What is missing is a function declaration with lexical this.

What’s the best way to solve this and to eliminate the pitfall of dynamic this (at least for beginners)? Tell people to const-bind arrow functions?

IMO, yes.

We’d lose hoisting, though.

yes. I don't think this will actually be a problem in practice.

I also wouldn’t want to lose the symmetry function declaration/generator declaration and method definition/generator method definition.

I do sometimes wish there was a natural place to put a "*" on an arrow function, and sometimes I don't wish it. In any case, it's not gonna happen in ES6.

IMO, we need a consistent story for ES6 in this area.

const foo = (a,b) => a+b;

For simple procedures-like function still

function doAction() { ... }

looks more familiar for programmers than

const doAction = () => {}

(notice also this ugly empty parameters thing = () =).

So I wouldn't kill function declarations and left the dynamic this there (which still can be used).

=> functions are mostly for one-time use, and short functions (even if the

have blocks). To avoid spaghetti code, usually if the function is big it's moved outside instead of using in-place.

Dmitry

# Axel Rauschmayer (11 years ago)

What’s the best way to solve this and to eliminate the pitfall of dynamic this (at least for beginners)? Tell people to const-bind arrow functions?

IMO, yes.

We’d lose hoisting, though.

yes. I don't think this will actually be a problem in practice.

That makes sense, thank you.

I also wouldn’t want to lose the symmetry function declaration/generator declaration and method definition/generator method definition.

I do sometimes wish there was a natural place to put a "*" on an arrow function, and sometimes I don't wish it. In any case, it's not gonna happen in ES6.

Given that generators use the this that the function would have (at least that’s how I read the spec – this is the global object for a non-strict generator function, undefined for a strict generator function, the receiver of the method invocation for a generator method), a generator arrow function would even be useful: a generator with lexical this.

# David Bruant (11 years ago)

Le 25/06/2013 02:36, Dmitry Soshnikov a écrit :

On Mon, Jun 24, 2013 at 5:00 PM, Mark S. Miller <erights at google.com <mailto:erights at google.com>> wrote:

On Mon, Jun 24, 2013 at 4:46 PM, Axel Rauschmayer
<axel at rauschma.de <mailto:axel at rauschma.de>> wrote:

    Sorry for bringing this point up, again. It is a minor point,
    but details matter if ECMAScript 6 is supposed to feel consistent.

    In general, I like how ECMAScript 6 has evolved functions.
    Before, functions played three roles:

    1. Constructor
    2. Method
    3. Non-method function (where you want lexical `this`)

    In ES6, we have classes for #1 and method definitions for #2
    (in both object literals and class literals). Furthermore,
    arrow functions replace function expressions and have lexical
    `this`. What is missing is a function declaration with lexical
    `this`.

    What's the best way to solve this and to eliminate the pitfall
    of dynamic `this` (at least for beginners)? Tell people to
    const-bind arrow functions?


IMO, yes.

    We'd lose hoisting, though.


yes. I don't think this will actually be a problem in practice.

    I also wouldn't want to lose the symmetry function
    declaration/generator declaration and method
    definition/generator method definition.


I do sometimes wish there was a natural place to put a "*" on an
arrow function, and sometimes I don't wish it. In any case, it's
not gonna happen in ES6.


    IMO, we need a consistent story for ES6 in this area.


const foo = (a,b) => a+b;

For simple procedures-like function still

function doAction() { ... }

looks more familiar for programmers than

const doAction = () => {}

You'd be surprised. I've read lots of files from different people where I was left wondering "why did he/she choose 'var x = function(){...}' over 'function x(){}'". In the end, there was no good reason.

# Allen Wirfs-Brock (11 years ago)

On Jun 24, 2013, at 11:37 PM, Axel Rauschmayer wrote:

Given that generators use the this that the function would have (at least that’s how I read the spec – this is the global object for a non-strict generator function, undefined for a strict generator function, the receiver of the method invocation for a generator method), a generator arrow function would even be useful: a generator with lexical this.

see ecmascript#1489

# Brendan Eich (11 years ago)

David Bruant wrote:

You'd be surprised. I've read lots of files from different people where I was left wondering "why did he/she choose 'var x = function(){...}' over 'function x(){}'". In the end, there was no good reason.

Crock recommends -- in talks and in JS:TGP too, IIRC.

But 'function x(){}' endures and predominates in my experience.

# Brendan Eich (11 years ago)

Allen Wirfs-Brock wrote:

On Jun 24, 2013, at 11:37 PM, Axel Rauschmayer wrote:

Given that generators use the this that the function would have (at least that’s how I read the spec – this is the global object for a non-strict generator function, undefined for a strict generator function, the receiver of the method invocation for a generator method), a generator arrow function would even be useful: a generator with lexical this.

see ecmascript#1489

Whew -- glad that ended up on the right page. :->

On generator arrows, I say YAGNI. Anyway, as Mark said: not for ES6.

# Axel Rauschmayer (11 years ago)

Given that generators use the this that the function would have (at least that’s how I read the spec – this is the global object for a non-strict generator function, undefined for a strict generator function, the receiver of the method invocation for a generator method), a generator arrow function would even be useful: a generator with lexical this.

see ecmascript#1489

Perfect. That’s how I thought it would work.