Discuss
  • please add orEqual operator

please add orEqual operator

# myemailum14 at gmail.com (9 years ago)

it could be used like this:

if ( a == 1 ||= 2 ||=3 ||=5) { //do something if a is either 1,2,3,5}

and it could be used like this

a || = 0 // a = a || 0

# Alexander Jones (9 years ago)

a ||= b looks like an in-place logical or, like +=.

a = a || b would have very different semantics to that which you propose.

In Python this would be written:

if a in [1, 2, 3, 5]:
    # stuff

In JS we have similar but slightly less semantic:

if ([1, 2, 3, 5].indexOf(a) > -1) {
    // stuff
}
# Michael A. Smith (9 years ago)

I was going to suggest a Set, now that ECMA has them… www.ecma-international.org/ecma-262/6.0/index.html#sec-set-objects

if ((new Set([1,2,3,5]).has(a)) {
    // stuff
}
# Isiah Meadows (9 years ago)

Or, there is the likely ES7 Array#contains for comparing multiple numbers.

[1, 2, 3].contains(value);

As for the operator proposed here, there's already an existing proposal for a safer version which doesn't coerce: strawman:default_operator.

# myemailum14 at gmail.com (9 years ago)

why create an array when there can be an operator. I think if we do survey people will like this, ||=, it's more expressive.

# myemailum14 at gmail.com (9 years ago)

Isn't

prop ||= 0;

better than

prop = prop || 0;

and it can be even defined like this.

prop ||= var1 ||= var2 ||= 0;

but then i dont know how we can use it ike this

if (num == 3 ||=4 ||=6)

# Jordan Harband (9 years ago)

fwiw, just like String#includes, "contains" has been renamed to Array#includes (see tc39/Array.prototype.includes)

# Peter van der Zee (9 years ago)

On Mon, Aug 10, 2015 at 3:50 AM, <myemailum14 at gmail.com> wrote:

Isn't prop ||= 0; better than prop = prop || 0; and it can be even defined like this. prop ||= var1 ||= var2 ||= 0; but then i dont know how we can use it ike this if (num == 3 ||=4 ||=6)

Sounds like you want two operators; ||= for the compound assignment case and ||== and ||=== for the "compare the RHS to the LHS of the last === or == op", or something like that. Defining a single op for both of these cases is likely to lead to ambiguity.

The ||= (and &&=) case has been discussed a couple of times, look in the esdiscuss archives. I'm sure something like ||== has been discussed too though I don't recall it myself. I tend to use switches myself for this in case perf is an issue.

# myemailum14 at gmail.com (9 years ago)

Thanks I'll be searching through archive, and yea i think this is something very simple and yet innovative.

# joe (9 years ago)

Isn't this what switch statements are for? Perhaps a condensed operator version of a switch would be useful?

if (a == 0 : 1 : 2) {
}

Or perhaps something similar to the set version, but without the set:

if (a of 1, 2, 3, 4, 5, 6) {
}

One could do this as a standard lib variadic function, I suppose:

if (select(a, 1, 2, 3, 4, 5, 6)) {
}
# Andrea Giammarchi (9 years ago)

On Mon, Aug 10, 2015 at 5:42 PM, joe <joeedh at gmail.com> wrote:

Isn't this what switch statements are for? Perhaps a condensed operator version of a switch would be useful?

if (a == 0 : 1 : 2) {
}

switch does eqeqeq comparison so is not exactly the same switch(1) { case true: console.log('never'); }

Or perhaps something similar to the set version, but without the set:

if (a of 1, 2, 3, 4, 5, 6) {
}

an if/of doesn't feel that right to me ... weird semantic

[1, 2, 3, 4, 5, 6].contains(a) looks better ?

One could do this as a standard lib variadic function, I suppose:

if (select(a, 1, 2, 3, 4, 5, 6)) {
}

No, the main point of having operators is that the engine could just skip the fallback part.

var a = 1 || doSomethingComplex(123)

as example, will never execute doSomethingComplex whilc passing any value as argument should be already resolved as value.

In any case, FWIW, I think this is a classic "nostalgia operator" asked from someone that uses from another PL or just started using JS ... I wouldn't mind some well integrated and well thought shortcut, but I feel like this should be the least priority for ES.next

Best

# joe (9 years ago)

I actually like [1, 2, 3, 4, 5, 6].contains(a) better, too. The question is, will engines actually optimize it. I have to admit, I don't trust people who say VMs or compilers will do the optimizing for you. I've had to track down vendor keywords to force C/C++ compilers to inline functions more than once, after the idiot thing's optimizers failed to do so, not even when I was using the inline keyword (which is an optimization hint, not an imperative).

I have never had this happen with only one compiler, either; if gcc won't inline a function, msvc won't either.

Instead of saying "the VMs probably will. . ." perhaps the TC39 committee should mandate that they do so formally, in the spec. Then people like me could stop violating bits of the standard that aren't workable with how today's VMs work, like the return value of .next methods in iterators.

Joe

# myemailum14 at gmail.com (9 years ago)

I one day writing js thought why there is no operator for ||= there should be syntax makes sense, then i learned some ruby and it had this already. Now i was convinced it makes sense afterall.

# Caitlin Potter (9 years ago)

I've had to track down vendor keywords to force C/C++ compilers to inline functions more than once, after the idiot thing's optimizers failed to do so, not even when I was using the inline keyword

Off topic, but remember that inlining isn’t always an optimization, and the compiler’s heuristics may actually be improving the performance of your build when it makes this choice! Of course they can still get it wrong, but..

It can be tricky for a method to do as good a job as a compiler could do, when optimizing this — for instance, a compiler may be able to eliminate redundant or unused tests entirely. A compiler can in some cases have static knowledge of the types of values it’s operating on, and save time accessing properties or invoking methods. A.p.includes will be O(n) in general, and there’s little the compiler can do to improve the algorithm. Beyond algorithmic improvements, you aren’t likely to see much optimization in the runtime function. But it probably doesn’t matter 99% of the time anyways, you probably aren’t going to rewrite a 1-liner into a huge switch statement or unreadable set of ternary expressions just to avoid that cost.

I’m quite sure someone will point out how wrong I am on any or all of the above points any moment now, I can’t wait =)

# Andrea Giammarchi (9 years ago)

well

On Mon, Aug 10, 2015 at 6:15 PM, joe <joeedh at gmail.com> wrote:

I actually like [1, 2, 3, 4, 5, 6].contains(a) better, too. The question is, will engines actually optimize it.

if the entire environment never touches even "by accident" the Array.prototype I don't see why that couldn't be optimized by the engine ... but in general, if a small Array#contains is the performance bottleneck of any application I think there's probably something else wrong there, or maybe the only better performance approach would be a switch with all cases well defined with a break (as someone somewhere suggested once about a speedy subset of JS)

# Herby Vojčík (9 years ago)

myemailum14 at gmail.com wrote:

I one day writing js thought why there is no operator for ||= there

The problem with || (and, consequently, ||=) is that it uses ToBoolean. We have all used to it, but I'd bet what we mostly want is "if (x == null) ...", so I think ||= should NOT be added to the language and || used as value || anotherValue should be left to rot (as a boolean short-circuit in if/while it is, of course, indispensable); on the other hand, we should add something like value ?? anotherValue and lvalue ??= anotherValue, instead, which would only kick in case of null/undefined.

# Brendan Eich (9 years ago)

Please search for older proposals on ecmascript.org. You'd find

strawman:default_operator

ES6 parameter default values took a look of wind out of this one's sails.

# Tab Atkins Jr. (9 years ago)

On Mon, Aug 10, 2015 at 1:53 PM, Brendan Eich <brendan at mozilla.org> wrote:

Please search for older proposals on ecmascript.org. You'd find

strawman:default_operator

ES6 parameter default values took a look of wind out of this one's sails.

You're pattern-matching incorrectly - this is not the default operator, it's "seeing if a var is any of several possible matches".

But yeah, as Alexander said, Python gets by just fine by creating an array or tuple and asking about membership; using [].contains() should be just fine in JS too.

# Isiah Meadows (9 years ago)

The original idea was a default assign operator, like CoffeeScript's ?=. And the idea of testing multiple values is currently best done with switch statements. I would love a simpler alternative, though. (This is something that engines could simply desugar, though, much like default arguments and rest arguments).

Although, to be honest, I'm seeing a lot of things on this list lately that really imply a need for patten matching and data types.

# joe (9 years ago)

I'm talking about cases where a failure to inline one function led to an order of magnitude performance loss. As a general rule, I only inline functions when I can demonstrate a measurable and significant performance gain, for the reasons you listed. My point is just that you shouldn't trust automatic optimization heuristics.

# joe (9 years ago)

Do you know why python gets away with that, though? It forcibly amortizes the GC cost by using a hybrid reference counting/cyclic collector scheme. That's not exactly fast, either, which is why no one else does it.

# Brendan Eich (9 years ago)

Oops, sorry.

You were punning with pattern-matching there ;-).

Can this thread die?

# Isiah Meadows (9 years ago)

Agreed.