For all new syntax proposals or discussions, I recommend writing a Babylon
plugin + Babel transform to prove that it's even possible before presenting
it for feedback.
Rick
On Tue, Nov 14, 2017 at 8:26 AM Isiah Meadows
wrote:
> Also, most decent text editors, including
Also, most decent text editors, including Atom, Sublime, Vim, and Emacs,
support such snippets. (Vim/Emacs call them macros, but they're
functionally the same concept mostly.)
On Tue, Nov 14, 2017, 01:48 T.J. Crowder
wrote:
> On Mon, Nov 13, 2017 at 10:22 PM,
On Mon, Nov 13, 2017 at 10:22 PM, Laurentiu Taschina <
source.spi...@gmail.com> wrote:
> > Are you worried about typing more characters? Use an IDE with
> > auto-complete, or snippets.
>
> The problem can not be easily fix'ed with snippets.
You forgot to say *why not*, veering off into not
the *this* in fat-arrows is irrelevant to frontend-developers who
prefer to use static functions to manipulate json-data, rather than
class instantiated-objects which are difficult to serialize /
reconstruct when baton-passing between frontend <-> backend.
On 11/14/17, Naveen Chawla
Arrow functions are preferable primarily because they don't allow a new
"this" which is otherwise the cause of a lot of confusion/bugs. The other
reason is terseness. ()=>{} / input=>output etc. So what value are you
adding for introducing a shorthand for an already defunct construct
(function)?
> Who uses functions instead of arrow functions and methods these days,
anyway? (I know, people who haven't adopted ES2015+)
In my previous message on the paragraph where I talked about how "let"
would suffer the same if it was longer I had some words about how we'll
eventually reach the stage
That sounds like a major V8 bug that [should be reported][1] - there
should be zero performance difference between an arrow function and a
normal ES5 function. They're completely equivalent apart from ES5
functions being constructible and arrow functions forming a closure
around the current call
On Sun, Nov 12, 2017 at 2:14 AM, T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:
> On Sun, Nov 12, 2017 at 9:56 AM, J Decker wrote:
> > Arrow functions passed as callback to Node.js addons execute 20%
> > slower than regular 'function()' functions.
>
> **Wow**. Is that
On Sun, Nov 12, 2017 at 9:56 AM, J Decker wrote:
> Arrow functions passed as callback to Node.js addons execute 20%
> slower than regular 'function()' functions.
**Wow**. Is that written up somewhere one could read more?
When you say "Node.js addon," are you excluding built-in
On Sun, Nov 12, 2017 at 1:11 AM, T.J. Crowder <
tj.crow...@farsightsoftware.com> wrote:
> On Sun, Nov 12, 2017 at 6:09 AM, Naveen Chawla
> wrote:
> >
> > Who uses functions instead of arrow functions and methods these
> > days, anyway? (I know, people who haven't adopted
On Sun, Nov 12, 2017 at 6:09 AM, Naveen Chawla
wrote:
>
> Who uses functions instead of arrow functions and methods these
> days, anyway? (I know, people who haven't adopted ES2015+)
Laurentiu's been fairly clear about his/her use case: Named inline
callbacks. I don't
Hahah...
- Michael
On Sun, Nov 12, 2017 at 2:09 PM, Naveen Chawla
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 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 wrote:
> Obviously we should use 퓕 or something like that. I'm sure it's been
> proposed, although I can't find it at
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
> 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
> 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
On Fri, Nov 10, 2017 at 7:25 PM, Laurentiu Taschina 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
> You're not going to have any luck getting `func`, `fn`, or `def` as a
keyword for this. Too much existing code would break. I'm certain I've used
all of those even just in my own code. Just about *any* short keyword is
going to have the same problem.
I think understand what you're thinking.
On Fri, Nov 10, 2017 at 4:47 PM, Allen Wirfs-Brock
wrote:
>
> An idiom that assigns names to arrow functions arguments:
Heh, I actually *wrote* that at one point in my reply to Laurentiu, then
removed it because it was still clunky. :-) It's less clunky when you
combine
An idiom that assigns names to arrow functions arguments:
```js
let add, mul; //used to name arrow functions
const sum = [1, 2, 3].reduce(add = (a, b) => a + b);
const product = [1, 2, 3].reduce(mul = (a, b) => a * b);
```
___
es-discuss mailing
On Fri, Nov 10, 2017 at 2:58 PM, Laurentiu Taschina
wrote:
> So useless for callback usage, which a very big chunk of the use cases.
That's very different from the statement "only regular functions can have
names" but I can see how you got there. :-)
So naming inline
Doesn't work if it's not pre-declared. [1] (see jsfiddle, a bit too long to
post here)
So useless for callback usage, which a very big chunk of the use cases.
While you can argue to kind-of get enough information (it says it's "each"
in chrome) with the other way, and having a name there is just
On Fri, Nov 10, 2017 at 1:11 PM, Laurentiu Taschina
wrote:
>
> I would like to propose the standard allow for shorthand form for
> the normal "function" keyword.
>
> ...
>
> Advantages & Motivation
>
> only regular functions can have names, but being so clunky people
>
Hello,
I would like to propose the standard allow for shorthand form for the
normal "function" keyword.
No other special meaning, just shorter (preferably at most 4 characters).
*Advantages & Motivation*
- the keyword often takes as much if not more space then the arguments,
almost
24 matches
Mail list logo