It's not just line 18, I barely have any idea what any lines are doing. Single letter variable names are almost always a bad idea except in one case, using `i` as an index, and even then I don't do that any more because `index` is more obvious.

Agreed! There's an open issue to address this - the single letter names are silly, since they get uglified anyway.

Yeah, saw the comment and opened an issue :D

For future reference: https://github.com/developit/greenlet/blob/8f51450aab0e1f988...

(The issues that were discussed in this thread had been resolved by the time I wrote this comment, and so the link above pointed to the wrong commit.)

Gah, that always gets me. Thanks.

after the web worker executes its function, it post a message to the original context with 3 arguments - the call id (c), error string(e), the successful result object(d).

the greenlet function when invoked returns a promise waiting to be resolved or rejected. the resolver and rejector functions are stored in object p with the key with a unique call id.

so line 18 `p[c][e?1:0](e||d);` basically means resolve or reject the promise based on the parameters from the web worker message by invoking either the resolve or reject function stored by its call id.

here's my quick attempt to understand and annotate this lib.

https://gist.github.com/zz85/25564f1910f1877c39c25ace5e5159b...

Wow! Nice! Thank you!! WOW!

I haven't touched Javascript for a long time, especially using shiny features in ES5, ES6... those arrows always throws me off. Is this a typical JS & NodeJS style nowadays? Does anyone ever feel your code and your co-workers' code are barely readable?

Disclaimer: Python programmer.

Not the parent, but I find function vs fat arrow to be similar to:

* def vs lambda in Python

* fn vs closures in Rust

* def vs anonymous functions in Elixir

Honestly, given how often I find myself using small, immediately-consumed functions when performing common filter/map/reduce operations I find fat arrows to be an extremely welcome addition. I feel that it spares a lot of excessive "function" keywords everywhere and gives you just a little more room to have more verbose variable names when you have to deal with things like enforced maximum line lengths...

I write JavaScript/Node everyday. In my experience one does not write code like this when working with a team or a project that will be handed off; the author(s) are trying to minimize file size with expressions that are as small as possible. This seems okay to me for a library where your API is simply a function wrapper.

Wow, yeah. It looks like it was uglified and then prettified.

If I had a desire to deeply understand JavaScript syntax, I'd probably use this as a learning task.

The syntactic complexity of line 18 isn’t really the issue (in fact, it shouldn’t really require a deep understanding of JS syntax), it’s the meaningless single-letter variable names.