Short Comparing proposal

Felipe Nascimento de Moura felipenmoura at
Sat Feb 4 04:07:07 UTC 2017

(pasting it kinda lost with some other e-mail mixing this thread)

I started the thread with this question because I thought exactly in both
performance (short circuit) and readability.

Bear with me:

// the expression
let x = a || b;
// could be
let x;
if (a) { x = a; }
else { x = b; }

So...the operator "||" in THIS particular case is also just an alternative,
and yet extremely useful (and used). It is short, and is it beautiful for
That OR could be the good old "if"! Even though, I use it everywhere I can.

// the expression
if (obj.prop.prop2 === 'a' : 'b' : 'c') { ... }
// could be
if (obj.prop.prop2 === 'a' || obj.prop.prop2 === 'b' || obj.prop.prop2 ===
'c') { ... }

I see the same feeling here...yes, we could use other approaches, we could
use destructors using the keys of an object...we could use [].contains,
[].some, switch/case...but this is a much more beautiful way of doing it :)

I don't think it would make sense for &&, once things are not supposed to
be equal to two different values

Again, just a suggestion, but one thing I like in JavaScript is its
readability and power of "deduction power".
The first time I read a code using || in an assignment (and I had no idea
what that was, much younger, learning by myself, not knowing english, with
almost zero access to internet), it toke me about 5 seconds to "guess" its simply makes sense.


On Thu, Feb 2, 2017 at 5:25 PM Jordan Harband <ljharb at> wrote:

It seems like a far more useful proposal (although much larger in scope)
would be some concept of interface comparison, and then you could see if
`object` matches "an interface that has an `a` and `b` property", but also
if `object` is "arraylike", or "iterable", or a "thenable", etc.

On Thu, Feb 2, 2017 at 12:46 AM, T.J. Crowder <
tj.crowder at> wrote:

On Wed, Feb 1, 2017 at 7:18 PM, Jeremy Darling <jeremy.darling at>

This is an interesting concept, but reuse of ()'s and : will make it
difficult to pin down, scale to other operators and communicate.  Really
the "inclusion" operator needs to be something that stands out, doesn't
break existing spec, and won't kill new specs.

Completely agreed. The trick is finding that something. We're definitely
out of single-character options, so something along the lines you describe
would be better. `$` is probably not going to be an option as the lead
character, as it's an identifier character.

I don't know how the process works, though. Is it too early to be thinking
about syntax? The first question probably has to be whether it's worth
exploring new syntax in this area at all, *then* exploring what that syntax
might be...

-- T.J.

es-discuss mailing list
es-discuss at

es-discuss mailing list
es-discuss at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list