arrow function syntax simplified

manuelbarzi manuelbarzi at gmail.com
Thu Oct 25 14:09:07 UTC 2018


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 <isiahmeadows at gmail.com>
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 <manuelbarzi at gmail.com> 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
>> 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/20181025/5141cacf/attachment.html>


More information about the es-discuss mailing list