arrow function syntax simplified

Ben Wiley therealbenwiley at gmail.com
Thu Oct 25 14:40:24 UTC 2018


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 <manuelbarzi at gmail.com> 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 <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
>>>
>> _______________________________________________
> 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/9188ed98/attachment-0001.html>


More information about the es-discuss mailing list