`trimStart` and `trimEnd` are better-named versions of the very very
long-existing `trimLeft` and `trimRight`, which lack this ability, along
with ES5's `trim`.
It wouldn't make sense for these three to differ.
It certainly seems like a potential language proposal to add a string
argument to all
I suppose what I'm making is a subjective argument, because there's no way
to precisely measure "cognitive load" or "utility," just certain rules of
thumb and guidelines passed down over the generations.
I suppose what it boils down to, is that I (subjectively) think that
there's a very high
Minor point, but the vast majority of JS is written in corporate
environments where code can't even be checked in unless it lints against
the company's standard lint rules. Modern linters support an incredible
variety of rules, including custom rulesets.
I am not saying that the availability of
FWIW a start to ```nameofall``` using ```RegExp```
https://gist.github.com/guest271314/daa1c6455ec8a2b6b89aff245e95c615
```const nameofall =
/((const|let)\s+)\w+(?=\s+(=|in|of))|class\s+\w+(?=\s)/gi;```
TODO: handle destructuring assignment, default values, shorthand
assignments, e.g.,
```
> Every language feature adds cognitive overhead. It is not something that
can or should be avoided. It should be minimized and balanced against other
factors.
True, though I'd still argue that adding a new way to generate a function
without either instantiating a function (with "()") or calling
I was expecting that someone brings up the brackets property accessor at some
point.
I would argue that there is a bit of syntactic inconsistency since usually when
using the bracket accessors it is not preceded by a dot.
```
const getEmail = user => user["contacts"].email; // No dot between
Every language feature adds cognitive overhead. It is not something that
can or should be avoided. It should be minimized and balanced against other
factors.
Whether some codebase uses the new ```.prop``` syntax, or ```R.pick```
(from Ramda), or ```pluck("p")```. from RxJS, or some third-party or
Howdy. First post to es-discuss.
I've been thinking about the proposal. I would recommend against it, main
reason being that it makes the language a bit harder to read and understand
at-a-glance.
Here's why. As an example, you've listed
```const getEmail = .contacts.email;```
as a possible
`String.prototype.padStart` and `String.prototype.padEnd` accept the string
to pad with as their final parameter. Is there any particular reason
`String.prototype.trimStart` and `String.prototype.trimEnd` don't do the
same? It would be nice to have a parallel, such that `'foo'.padEnd(10,
Let me correct one thing.
This proposal has nothing to do with ```|>```.
>
What I meant to say is that the two proposals are not interdependent or
related, but since ```.p``` is to be a function retrieving the value of
property ```p```, it can be used like any other function in a pipline, and
I am guessing this doesn't allow any operations other than the "dot path"
to a function or property... Are you comfortable with that? If so, why? I
have found myself doing things like a=>a.x/2 . I couldn't do that in
proposed way, could I? Have you found, in your experience, that a "dot path
only"
> In any event, re-read the proposal. Am certainly not opposed to the
JavaScript language being capable of golf by default. Is the gist of the
proposal to substitute ```|>```, and or ```.``` at ```const getEmail =
.contacts.email;``` as the first character after ```=``` for `=>`, meaning
the
12 matches
Mail list logo
