Re: Re: arrow function syntax simplified

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

Re: Re: arrow function syntax simplified

manuelbarzi
taking this old discussion back a bit (https://esdiscuss.org/topic/arrow-function-syntax-simplified), why shouldn't be a good idea to deprecate the use of "function" in pro of thin-arrow "->", being applicable in same cases (including named function)?

just a bit of code with more about proposals:

const GLOBAL_FACTOR = 2

const result = [1, 2, 3].map(function(value) { return GLOBAL_FACTOR * value })

// PROPOSAL 1 - normal anonymous function (same as fat-arrow, but dynamic binding, nothing much new here as from previous proposals):
// const result = [1, 2, 3].map(value -> GLOBAL_FACTOR * value)


function applyFactor(value) {
return GLOBAL_FACTOR * value
}

// PROPOSAL 2 - named function declaration (without 'function' keyword):
// applyFactor(value) -> GLOBAL_FACTOR * value

// referenced function (following PROPOSAL 1):
// const applyFactor = value -> GLOBAL_FACTOR * value

const sameResult = [1, 2, 3].map(applyFactor)

justification i read against this proposal is mainly that thin-arrow may bring "more confusion" and may "provide poor or no benefit" co-existing with fat-arrow. but having both may bring devs the chance to understand the differences in the learning process as any other feature. the only "big deal" would be to be aware of fix vs dynamic binding, which is something a dev must understand sooner or later, independently of syntax (it can be just explained with traditional function() {} and .bind() method).

on the other hand it would bring the chance to avoid over-using fat-arrow when binding it's not really necessary (which may "save" internal binding processing too).

finally, a simpler and shorter syntax avoiding the requirement of the keyword 'function'.



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

Re: Re: arrow function syntax simplified

Isiah Meadows-2
Couple nita about your argunents:

1. Most commonly used implementations don't close over more than what they have to. If `this` isn't used, it's not closed over. The addition of one more variable to check has so little overhead you won't gain anything.

2. Deprecating anything in JS is hard in general. The little-used `arguments.caller` itself was a challenge.

Not TC39, but I strongly doubt this would have any traction for these + your additional justifications against.

On Thu, Oct 25, 2018 at 06:59 manuelbarzi <[hidden email]> wrote:
taking this old discussion back a bit (https://esdiscuss.org/topic/arrow-function-syntax-simplified), why shouldn't be a good idea to deprecate the use of "function" in pro of thin-arrow "->", being applicable in same cases (including named function)?

just a bit of code with more about proposals:

const GLOBAL_FACTOR = 2

const result = [1, 2, 3].map(function(value) { return GLOBAL_FACTOR * value })

// PROPOSAL 1 - normal anonymous function (same as fat-arrow, but dynamic binding, nothing much new here as from previous proposals):
// const result = [1, 2, 3].map(value -> GLOBAL_FACTOR * value)


function applyFactor(value) {
return GLOBAL_FACTOR * value
}

// PROPOSAL 2 - named function declaration (without 'function' keyword):
// applyFactor(value) -> GLOBAL_FACTOR * value

// referenced function (following PROPOSAL 1):
// const applyFactor = value -> GLOBAL_FACTOR * value

const sameResult = [1, 2, 3].map(applyFactor)

justification i read against this proposal is mainly that thin-arrow may bring "more confusion" and may "provide poor or no benefit" co-existing with fat-arrow. but having both may bring devs the chance to understand the differences in the learning process as any other feature. the only "big deal" would be to be aware of fix vs dynamic binding, which is something a dev must understand sooner or later, independently of syntax (it can be just explained with traditional function() {} and .bind() method).

on the other hand it would bring the chance to avoid over-using fat-arrow when binding it's not really necessary (which may "save" internal binding processing too).

finally, a simpler and shorter syntax avoiding the requirement of the keyword 'function'.


_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Re: arrow function syntax simplified

manuelbarzi
ok.

as little example, what if - for any case - you would explicitly require a function not to be auto-binded anymore, then in the current situation you would need to switch code from fat-arrow `() => ...` to bureaucratic `function() { ... }`. with thin-arrow you would just need to change symbol `=` by `-`, ending in just `() -> ...`. i guess this simplicity may sound trivial, but it would be aligned with and ease while coding, making es+ still thinking beyond, upon this situations and similar others (apart from the visible shortness and simplicity when writing `() -> ...` instead of `function() { ... }`).

let's bring a little example on expressing an operation to be applied on an object by itself:

```
const o = {
do(expression) {
expression.call(this)
    }
}

// cant apply or call on fat-arrow (as already binded to outer context)
//o.do(() => this.name = 'object') // won't work

// would then need to switch it to wordy `function` expression
o.do(function() { this.name = 'object' })

// but following PROPOSAL1, would just be (shorter and simpler):
// o.do(() -> this.name = 'object')

console.log(o.name)
```
needless to say, less characters, more compressed code.

On Thu, Oct 25, 2018 at 1:10 PM Isiah Meadows <[hidden email]> wrote:
Couple nita about your argunents:

1. Most commonly used implementations don't close over more than what they have to. If `this` isn't used, it's not closed over. The addition of one more variable to check has so little overhead you won't gain anything.

2. Deprecating anything in JS is hard in general. The little-used `arguments.caller` itself was a challenge.

Not TC39, but I strongly doubt this would have any traction for these + your additional justifications against.

On Thu, Oct 25, 2018 at 06:59 manuelbarzi <[hidden email]> wrote:
taking this old discussion back a bit (https://esdiscuss.org/topic/arrow-function-syntax-simplified), why shouldn't be a good idea to deprecate the use of "function" in pro of thin-arrow "->", being applicable in same cases (including named function)?

just a bit of code with more about proposals:

const GLOBAL_FACTOR = 2

const result = [1, 2, 3].map(function(value) { return GLOBAL_FACTOR * value })

// PROPOSAL 1 - normal anonymous function (same as fat-arrow, but dynamic binding, nothing much new here as from previous proposals):
// const result = [1, 2, 3].map(value -> GLOBAL_FACTOR * value)


function applyFactor(value) {
return GLOBAL_FACTOR * value
}

// PROPOSAL 2 - named function declaration (without 'function' keyword):
// applyFactor(value) -> GLOBAL_FACTOR * value

// referenced function (following PROPOSAL 1):
// const applyFactor = value -> GLOBAL_FACTOR * value

const sameResult = [1, 2, 3].map(applyFactor)

justification i read against this proposal is mainly that thin-arrow may bring "more confusion" and may "provide poor or no benefit" co-existing with fat-arrow. but having both may bring devs the chance to understand the differences in the learning process as any other feature. the only "big deal" would be to be aware of fix vs dynamic binding, which is something a dev must understand sooner or later, independently of syntax (it can be just explained with traditional function() {} and .bind() method).

on the other hand it would bring the chance to avoid over-using fat-arrow when binding it's not really necessary (which may "save" internal binding processing too).

finally, a simpler and shorter syntax avoiding the requirement of the keyword 'function'.


_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: Re: arrow function syntax simplified

Ben Wiley
Purely from the standpoint of convincing people not to use fat arrows only because they look more cute or whatever, this would be a great addition to the language. The decision would then become which arrow is best for the use case, no longer some trivial aesthetic argument.

Le jeu. 25 oct. 2018 10 h 09, manuelbarzi <[hidden email]> a écrit :
ok.

as little example, what if - for any case - you would explicitly require a function not to be auto-binded anymore, then in the current situation you would need to switch code from fat-arrow `() => ...` to bureaucratic `function() { ... }`. with thin-arrow you would just need to change symbol `=` by `-`, ending in just `() -> ...`. i guess this simplicity may sound trivial, but it would be aligned with and ease while coding, making es+ still thinking beyond, upon this situations and similar others (apart from the visible shortness and simplicity when writing `() -> ...` instead of `function() { ... }`).

let's bring a little example on expressing an operation to be applied on an object by itself:

```
const o = {
do(expression) {
expression.call(this)
    }
}

// cant apply or call on fat-arrow (as already binded to outer context)
//o.do(() => this.name = 'object') // won't work

// would then need to switch it to wordy `function` expression
o.do(function() { this.name = 'object' })

// but following PROPOSAL1, would just be (shorter and simpler):
// o.do(() -> this.name = 'object')

console.log(o.name)
```
needless to say, less characters, more compressed code.

On Thu, Oct 25, 2018 at 1:10 PM Isiah Meadows <[hidden email]> wrote:
Couple nita about your argunents:

1. Most commonly used implementations don't close over more than what they have to. If `this` isn't used, it's not closed over. The addition of one more variable to check has so little overhead you won't gain anything.

2. Deprecating anything in JS is hard in general. The little-used `arguments.caller` itself was a challenge.

Not TC39, but I strongly doubt this would have any traction for these + your additional justifications against.

On Thu, Oct 25, 2018 at 06:59 manuelbarzi <[hidden email]> wrote:
taking this old discussion back a bit (https://esdiscuss.org/topic/arrow-function-syntax-simplified), why shouldn't be a good idea to deprecate the use of "function" in pro of thin-arrow "->", being applicable in same cases (including named function)?

just a bit of code with more about proposals:

const GLOBAL_FACTOR = 2

const result = [1, 2, 3].map(function(value) { return GLOBAL_FACTOR * value })

// PROPOSAL 1 - normal anonymous function (same as fat-arrow, but dynamic binding, nothing much new here as from previous proposals):
// const result = [1, 2, 3].map(value -> GLOBAL_FACTOR * value)


function applyFactor(value) {
return GLOBAL_FACTOR * value
}

// PROPOSAL 2 - named function declaration (without 'function' keyword):
// applyFactor(value) -> GLOBAL_FACTOR * value

// referenced function (following PROPOSAL 1):
// const applyFactor = value -> GLOBAL_FACTOR * value

const sameResult = [1, 2, 3].map(applyFactor)

justification i read against this proposal is mainly that thin-arrow may bring "more confusion" and may "provide poor or no benefit" co-existing with fat-arrow. but having both may bring devs the chance to understand the differences in the learning process as any other feature. the only "big deal" would be to be aware of fix vs dynamic binding, which is something a dev must understand sooner or later, independently of syntax (it can be just explained with traditional function() {} and .bind() method).

on the other hand it would bring the chance to avoid over-using fat-arrow when binding it's not really necessary (which may "save" internal binding processing too).

finally, a simpler and shorter syntax avoiding the requirement of the keyword 'function'.


_______________________________________________
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

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

Re: Re: arrow function syntax simplified

manuelbarzi
not focussing on aesthetics, but on reduce of bureaucracy, which not by coincidence it's something fat-arrow functions already provide.

On Thu, Oct 25, 2018 at 4:40 PM Ben Wiley <[hidden email]> wrote:
Purely from the standpoint of convincing people not to use fat arrows only because they look more cute or whatever, this would be a great addition to the language. The decision would then become which arrow is best for the use case, no longer some trivial aesthetic argument.

Le jeu. 25 oct. 2018 10 h 09, manuelbarzi <[hidden email]> a écrit :
ok.

as little example, what if - for any case - you would explicitly require a function not to be auto-binded anymore, then in the current situation you would need to switch code from fat-arrow `() => ...` to bureaucratic `function() { ... }`. with thin-arrow you would just need to change symbol `=` by `-`, ending in just `() -> ...`. i guess this simplicity may sound trivial, but it would be aligned with and ease while coding, making es+ still thinking beyond, upon this situations and similar others (apart from the visible shortness and simplicity when writing `() -> ...` instead of `function() { ... }`).

let's bring a little example on expressing an operation to be applied on an object by itself:

```
const o = {
do(expression) {
expression.call(this)
    }
}

// cant apply or call on fat-arrow (as already binded to outer context)
//o.do(() => this.name = 'object') // won't work

// would then need to switch it to wordy `function` expression
o.do(function() { this.name = 'object' })

// but following PROPOSAL1, would just be (shorter and simpler):
// o.do(() -> this.name = 'object')

console.log(o.name)
```
needless to say, less characters, more compressed code.

On Thu, Oct 25, 2018 at 1:10 PM Isiah Meadows <[hidden email]> wrote:
Couple nita about your argunents:

1. Most commonly used implementations don't close over more than what they have to. If `this` isn't used, it's not closed over. The addition of one more variable to check has so little overhead you won't gain anything.

2. Deprecating anything in JS is hard in general. The little-used `arguments.caller` itself was a challenge.

Not TC39, but I strongly doubt this would have any traction for these + your additional justifications against.

On Thu, Oct 25, 2018 at 06:59 manuelbarzi <[hidden email]> wrote:
taking this old discussion back a bit (https://esdiscuss.org/topic/arrow-function-syntax-simplified), why shouldn't be a good idea to deprecate the use of "function" in pro of thin-arrow "->", being applicable in same cases (including named function)?

just a bit of code with more about proposals:

const GLOBAL_FACTOR = 2

const result = [1, 2, 3].map(function(value) { return GLOBAL_FACTOR * value })

// PROPOSAL 1 - normal anonymous function (same as fat-arrow, but dynamic binding, nothing much new here as from previous proposals):
// const result = [1, 2, 3].map(value -> GLOBAL_FACTOR * value)


function applyFactor(value) {
return GLOBAL_FACTOR * value
}

// PROPOSAL 2 - named function declaration (without 'function' keyword):
// applyFactor(value) -> GLOBAL_FACTOR * value

// referenced function (following PROPOSAL 1):
// const applyFactor = value -> GLOBAL_FACTOR * value

const sameResult = [1, 2, 3].map(applyFactor)

justification i read against this proposal is mainly that thin-arrow may bring "more confusion" and may "provide poor or no benefit" co-existing with fat-arrow. but having both may bring devs the chance to understand the differences in the learning process as any other feature. the only "big deal" would be to be aware of fix vs dynamic binding, which is something a dev must understand sooner or later, independently of syntax (it can be just explained with traditional function() {} and .bind() method).

on the other hand it would bring the chance to avoid over-using fat-arrow when binding it's not really necessary (which may "save" internal binding processing too).

finally, a simpler and shorter syntax avoiding the requirement of the keyword 'function'.


_______________________________________________
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

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

Re: Re: arrow function syntax simplified

Dan Aprahamian
In reply to this post by manuelbarzi
IMHO this would be a cool feature. But when you consider that there are a limited number of operators available for future language features, it seems like this provides very little gain for consuming that operator. 
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: arrow function syntax simplified

manuelbarzi
what about the simplification in coding, decrease of bureaucracy, reduction of characters, i.e. increase in code compression possibilities?

On Thu, 25 Oct 2018 at 17:26, Dan Aprahamian <[hidden email]> wrote:
IMHO this would be a cool feature. But when you consider that there are a limited number of operators available for future language features, it seems like this provides very little gain for consuming that operator.  _______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: arrow function syntax simplified

Waldemar Horwat
In reply to this post by manuelbarzi
On 10/25/2018 07:55 AM, manuelbarzi wrote:
> not focussing on aesthetics, but on reduce of bureaucracy, which not by coincidence it's something fat-arrow functions already provide.

The committee has been swamped with numerous such syntax proposals.  While any single one may be reasonable in isolation, each one adds significant complexity to the language, and the sum of them is too great (plus multiple proposals try to grab the same syntax for different purposes).

You will not be able to deprecate `function`, as that's just not web-compatible.  Given the existing two syntaxes for defining functions (function and =>), creating a third one would just add complexity.

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

Re: arrow function syntax simplified

manuelbarzi
The committee has been swamped with numerous such syntax proposals.  While any single one may be reasonable in isolation, each one adds significant complexity to the language, and the sum of them is too great (plus multiple proposals try to grab the same syntax for different purposes).

AFAIS this proposal does not collide with any other one pointing to same syntax. it's just one more push on same direction to the initial proposal (already linked before). plus adding the PROPOSAL 2 for named functions:

```
function applyFactor(value) {
return GLOBAL_FACTOR * value
}

// PROPOSAL 2 - named function declaration (without 'function' keyword):
// applyFactor(value) -> GLOBAL_FACTOR * value
```
 
You will not be able to deprecate `function`, as that's just not web-compatible.  

"deprecation" could be progressive while keeping back-compat and encouraging users to switch to shorthand syntax of functions (and named functions) by means of thin-arrows. there's no intention to abruptly break anything. 

Given the existing two syntaxes for defining functions (function and =>), creating a third one would just add complexity.
 
would not that "complexity" be worth it, in favor of less bureaucracy and code compression?

why would just adding a shorthand syntax to functions with thin-arrows would be that "complexity drama"? because people would mix functions and thin-arrows? that's already a reality with code using functions and fat-arrows, and AFAIK nobody complains about it. the only diff here is just to be aware of when to auto-bind (`=>`) or not to auto-bind (`->`). don't see any drama with that.



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

Re: arrow function syntax simplified

Dan Aprahamian
In reply to this post by manuelbarzi
Honestly, I doubt there is much benefit in compression as long as you are gzip-ing. In a typical application, the benefit will be on the order of bytes.

I don't see this as a simplification in coding. For me, it is a lot easier to see the difference between `function` and `=>`, while `->` vs `=>` is a lot harder. I could see beginners getting very confused by this.

On Thu, Oct 25, 2018, 17:46 manuelbarzi <[hidden email]> wrote:
what about the simplification in coding, decrease of bureaucracy, reduction of characters, i.e. increase in code compression possibilities?

On Thu, 25 Oct 2018 at 17:26, Dan Aprahamian <[hidden email]> wrote:
IMHO this would be a cool feature. But when you consider that there are a limited number of operators available for future language features, it seems like this provides very little gain for consuming that operator.  _______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: arrow function syntax simplified

Waldemar Horwat
In reply to this post by manuelbarzi
On 10/25/2018 04:04 PM, manuelbarzi wrote:
>     The committee has been swamped with numerous such syntax proposals.  While any single one may be reasonable in isolation, each one adds significant complexity to the language, and the sum of them is too great (plus multiple proposals try to grab the same syntax for different purposes).
>
> AFAIS this proposal does not collide with any other one pointing to same syntax.

I've seen informal proposals that do something else with ->.

>     Given the existing two syntaxes for defining functions (function and =>), creating a third one would just add complexity.
>
> would not that "complexity" be worth it, in favor of less bureaucracy and code compression?

No.

> why would just adding a shorthand syntax to functions with thin-arrows would be that "complexity drama"? because people would mix functions and thin-arrows? that's already a reality with code using functions and fat-arrows, and AFAIK nobody complains about it. the only diff here is just to be aware of when to auto-bind (`=>`) or not to auto-bind (`->`). don't see any drama with that.

That's actually the major source of the drama.  The difference between => and -> would be subtle enough that it would be hard for casual users to keep track of which is which.

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