Allow arrow functions with conventional 'function' declarations

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Allow arrow functions with conventional 'function' declarations

Michael Luder-Rosefield
You're probably asking what on Earth the point of this is, and I'll tell you: _hoisting_.

My preferred ES5 code style was always to declare functions after their use:

```
doSomething1();
doSomething2();

function doSomething1 () {
  // ...
}

function doSomething2 () {
  // ...
}

It keeps things uncluttered and readable: you don't have to read through random functions before they are used, and have to work out what they're doing there.

If you're able to make use of ES6 arrow functions declared with `const`/`let`, though, you would have to declare them before use. This obviously goes against my preferred style, and can also result in inconsistent placing of function declarations when mixed with conventional functions.

My proposal is simple: after the initial `function name (params)`, allow the following forms:
1. { // body code } 
2. => { // body code }
3. => // expression ;

1. is of course the current form
2. is similar, except it's a block body arrow function (all the usual arrow function differences apply; this binding, cannot be used with 'new', no 'arguments', no 'super'...)
3. allows for concise body arrow functions - semi-colon at end.

Example:

```
// with proposal
doSomething1();
doSomething2()
  .then(doSomething3);

function doSomething1 () {
 // conventional function
}

function doSomething2 () => {
 // block body arrow function
}

function doSomething3 (value) => value ? foo(value) : bar();

// without proposal
const doSomething2 = () => { 
  // block body arrow function
  };
doSomething3 = value => value ? foo(value) : bar();

doSomething1();
doSomething2()
  .then(doSomething3);

function doSomething1 () {
 // conventional function
}
```
As you can see, the latter code is just... messy and unpleasant.

I don't think there's any potential issues in regards to interpreting syntax (it just requires a simple check for an arrow after the parameters), nor with readability. Async We would definitely need to clarify behaviour with `async` and generator functions, though.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Allow arrow functions with conventional 'function' declarations

Michael J. Ryan
While I appreciate your sentiment, and often relied on housing myself.  These days I'd be inclined to continue with the classic funny definition and hosting, or more likely to break it into a separate, testable module.

Not to be contain.

On Thu, Mar 29, 2018, 02:31 Michael Luder-Rosefield <[hidden email]> wrote:
You're probably asking what on Earth the point of this is, and I'll tell you: _hoisting_.

My preferred ES5 code style was always to declare functions after their use:

```
doSomething1();
doSomething2();

function doSomething1 () {
  // ...
}

function doSomething2 () {
  // ...
}

It keeps things uncluttered and readable: you don't have to read through random functions before they are used, and have to work out what they're doing there.

If you're able to make use of ES6 arrow functions declared with `const`/`let`, though, you would have to declare them before use. This obviously goes against my preferred style, and can also result in inconsistent placing of function declarations when mixed with conventional functions.

My proposal is simple: after the initial `function name (params)`, allow the following forms:
1. { // body code } 
2. => { // body code }
3. => // expression ;

1. is of course the current form
2. is similar, except it's a block body arrow function (all the usual arrow function differences apply; this binding, cannot be used with 'new', no 'arguments', no 'super'...)
3. allows for concise body arrow functions - semi-colon at end.

Example:

```
// with proposal
doSomething1();
doSomething2()
  .then(doSomething3);

function doSomething1 () {
 // conventional function
}

function doSomething2 () => {
 // block body arrow function
}

function doSomething3 (value) => value ? foo(value) : bar();

// without proposal
const doSomething2 = () => { 
  // block body arrow function
  };
doSomething3 = value => value ? foo(value) : bar();

doSomething1();
doSomething2()
  .then(doSomething3);

function doSomething1 () {
 // conventional function
}
```
As you can see, the latter code is just... messy and unpleasant.

I don't think there's any potential issues in regards to interpreting syntax (it just requires a simple check for an arrow after the parameters), nor with readability. Async We would definitely need to clarify behaviour with `async` and generator functions, though.
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss