Hahah...
- Michael
On Sun, Nov 12, 2017 at 2:09 PM, Naveen Chawla <naveen.c...@gmail.com>
wrote:
> Who uses functions instead of arrow functions and methods these days,
> anyway? (I know, people who haven't adopted ES2015+)
>
> On Sun, 12 Nov 2017 at 09:53 Bob Myers <r...@gol.com> wrote:
>
>> Obviously we should use š¯“• or something like that. I'm sure it's been
>> proposed, although I can't find it at the moment. Yes, I know all the
>> reasons why that's a bad idea.
>>
>> But come on.
>> Are you worried about typing more characters? Use an IDE with
>> auto-complete, or snippets.
>> Are you worried about payload size on the wire? Zipping makes it
>> virtually irrelevant.
>>
>> Bob
>>
>> On Sun, Nov 12, 2017 at 9:30 AM, Laurentiu Taschina <
>> source.spi...@gmail.com> wrote:
>>
>>> > The only benefit seems to be saving a few characters. The costs being
>>> an increase in complexity in the ways you can define a function, an
>>> increase in the complexity of parsing for functions, and the need to endure
>>> a candidate stage process for the removal of a few characters. To me, the
>>> costs far outweigh the benefit of just using the existing ways of declaring
>>> functions.
>>>
>>> I believe you're being unfair here. It's obviously not just 4 characters
>>> when it's such a common construct. If "let" was 3 words instead of 3
>>> letters, like say "assign variable value" what do you think would happen?
>>> Would people think of it as "just 18 more characters". No, people would
>>> ignore it completely no matter it's usefulness or correctness and world
>>> continue to use "var" exclusively.
>>>
>>> The cost of not changing it is that people will slowly and surely
>>> gravitate to avoiding using "function" ever (if they can), and thus the
>>> construct that can be named falls out of favor. And history has shown it
>>> happens, particularly in javascript, given the popularity of $ and _ for a
>>> good number of libraries, and at the same time the unpopularity of
>>> perfectly usable but tooLongToTypeNamed native versions. Of course in large
>>> part it's ease of use and consistency and all that, but the first thing I
>>> ever hear they being sold on is how short/easy they are. Looking at other
>>> cases today you have the situation of things like Kotlin vs Java, or swift
>>> vs objective C. From Kotlin's site it literally gets described as "Concise,
>>> simple and very easy to read (and write)" in their first example. But even
>>> looking at just javascript's past, people clearly care enough to make their
>>> own divergent language just to get it have things be shorterā€”and if they
>>> can't do that, then the next best thing is to misuse the language.
>>>
>>> This wouldn't maybe be a particular big issue, but javascript is
>>> more-or-less "build complex functions with a bunch of small functions."
>>> Callbacks imply lots of functions, promises imply a lot of functions,
>>> functions are usually split into lots of smaller single-use-functions,
>>> functions often times return functions, etc.
>>>
>>> Anonymous functions are already kind of annoyance born of laziness but
>>> with arrow functions (and how they can not easily have a name in the
>>> context of a callback) they're becoming particularly routed into the
>>> language. I think at this point people looking at a stack trace seeing the
>>> callbacks named will look at it as something strange. Don't you think that
>>> it's strange that that's normal?
>>>
>>> With regard to the difficulties of this going though, I could have
>>> presented the some-greatest-feature-ever and you could have just
>>> copy/pasted that 2nd part of your sentence there to shoot it down. All I'll
>>> say is that it's just a synonym to an existing thing (even let is more
>>> complex), for users it's just an nicer version that helps with moving away
>>> from anonymous functions (you wouldnt really ever need to use "function"
>>> ever again, much like you dont need "var" now). And as far as implementing
>>> goes, if we were to create javascript form scratch would we actually use
>>> "function" as the keyword for creating functions and all the other
>>> overlyLongMethodNames? I don't think so, every other programming language
>>> doesn't seem to think so, with how concise most libraries are written the
>>> community doesn't seem to think so, and even the language javascript
>>> presumably copied those habits from probably no longer thinks so anymore. I
>>> think even with out other benefits just getting closer to the language that
>>> everyone thinks it should have been like is valuable enough to warrant the
>>> hassle. I assume that's the very reason we have let now too.
>>>
>>>
>>> On Sat, Nov 11, 2017 at 1:00 AM, Eli Perelman <e...@eliperelman.com>
>>> wrote:
>>>
>>>> > I'm having trouble believing saving a couple of characters will have
>>>> the weight to make it happen
>>>>
>>>> I think this is the crux of the issue. What is the cost vs. benefit of
>>>> the proposal, and do these benefits outweigh the tradeoffs?
>>>>
>>>> The only benefit seems to be saving a few characters. The costs being
>>>> an increase in complexity in the ways you can define a function, an
>>>> increase in the complexity of parsing for functions, and the need to endure
>>>> a candidate stage process for the removal of a few characters. To me, the
>>>> costs far outweigh the benefit of just using the existing ways of declaring
>>>> functions.
>>>>
>>>> TLDR; to me this is -1.
>>>>
>>>> Eli Perelman
>>>>
>>>> On Fri, Nov 10, 2017 at 4:51 PM T.J. Crowder <
>>>> tj.crow...@farsightsoftware.com> wrote:
>>>>
>>>>> On Fri, Nov 10, 2017 at 7:25 PM, Laurentiu Taschina <
>>>>> source.spi...@gmail.com> wrote...
>>>>>
>>>>> So the TL;DR of all that is: You think `func` (or whatever) can be an
>>>>> identifier or keyword based on context.
>>>>>
>>>>> Well, quite true, it's certainly been done before (`async` for
>>>>> instance). All I'll say is: Good luck with that, for this purpose. :-)
>>>>>
>>>>> I'll flag up an ASI gotcha you'll need to avoid: When defining `func`
>>>>> function definitions, you'll need "[no LineTerminator here]" after the
>>>>> closing `)` of the parameter list. Why? Because otherwise this is a
>>>>> function call followed by a standalone block thanks to ASI:
>>>>>
>>>>> ```js
>>>>> let a = func()
>>>>> { console.log("blah"); };
>>>>> ```
>>>>>
>>>>> (Which is why AsyncFunctionDefinition has "[no LineTerminator
>>>>> here]" after `async`.) But again: It's been done before, so...
>>>>>
>>>>> I'm having trouble believing saving a couple of characters will have
>>>>> the weight to make it happen, and personally wouldn't favor it, but
>>>>> frankly
>>>>> that doesn't mean anything.
>>>>>
>>>>> -- T.J. Crowder
>>>>> _______________________________________________
>>>>> es-discuss mailing list
>>>>> es-discuss@mozilla.org
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
