Discuss
  • New Assignment Operators (Not bit-wise OR)

New Assignment Operators (Not bit-wise OR)

# even stensberg (9 years ago)

I've seen a lot of code using an extra type to have as a fallback. This to me seems like not a very good way of putting use of the logical OR. Here's an example:

var itemList = itemList || 'something went extremely wrong'

This is a really hacky way of doing things. I don't think you should assign your variable to a default by doing this.

Been back and forth by this "issue" with some of the ReactJS members at GitHub, and while saying this is a "stylus" thing, I disagree. It is more about not reiterating your code.

Options could be:

-Tenaries, which will result in long & !clean code lines, or default params (ES), of which, won't be a general use case when it comes down to supporting the feature fully.

There are already lots of assignments out there, but I don't really see any of them touch this, except maybe the bit-wise OR assignment Operator. To read more about that, check out these three links:

msdn.microsoft.com/en-us/library/81bads72(v=vs.94).aspx

web.eecs.umich.edu/~bartlett/jsops.html

stackoverflow.com/a/14871137/5893008

And that is really not the use case here. We don't want a bit-wise, we want a logical OR.

So here is what I've come up with. It's not rocket science but ... nah, it's pretty straight forward..

var listItem || = 'I love open source!'

For me, this is one thousand times better and it makes sense too. JavaScript teaches us and wants us to use + =,- = and any other type of "abbreviation" , so this makes perfectly sense, enhancing assignments even more. One way or another, it seems like this should have been implemented a long time ago, not when it's broadly used.

Implementation will be another issue, but let us discuss that too( just keep in mind this is conceptional)

Without further ado, I leave this up to you to discuss, and hopefully a champion to fetch up to the committee.

# Jordan Harband (9 years ago)

This has been discussed many times before:

If you read through these threads, you may find that it's not as straightforward as you think. Would it use truthiness? "not null or undefined"? Just "not undefined"? If it behaves differently than II, what about all the confusion that would cause, since it would be the first "LHS x-equals RHS" that didn't behave the same as "LHS equals LHS x RHS"?

A proposal would, at the least, need to have addressed all these concerns as well as made it clear that it had located and addressed all prior concerns on the subject, such as the ones linked above.

# even stensberg (9 years ago)

Could we use XOR? We would set the variable to false by default, meaning if it doesn't contain any values, it will return the OR property. By example:

true is a string and boolean in the first example and boolean in the other one.

var false = false || 'true' This means: false XOR false XOR true = true if it is set, we use true XOR true XOR false = false , which will return the value of our variable.

Example by function: function() { var false = true evalToTrue() // outputs 'true' }

function() { var false = false evalToTrue() // outputs the value of false }

evalToTrue() here means the XOR calculation.

This might be a duplicate of what someone else have already said though, we can swap out falsy with undefined etc I assume.

# even stensberg (9 years ago)

I wrote up this medium article describing a new way medium.com/@ev1stensberg/iteration-in-javascript-needs-a-tectonic-shift-a74b6554bbd7#.6cff5a1r7 , good enough to submit a proposal? It will need some fixes in syntax, but I think this could be a nice / decent fix.

# Michael Theriot (9 years ago)

What scenarios do you need to declare a new variable equal to its current declaration or a default value?

# even stensberg (9 years ago)

It's not a situation, but rather in my eyes a cleaner way of declaration. Have you read the article? Also, having this, makes it more explicit, as it should pass down values in a one way flow. Here's a gist with an example: goo.gl/1qyjNl . This distracts us a bit from the scenario though, as I was trying to tell @brendaneich ( and was wrong about) over Twitter.

The main idea is to make the copy of the variable prefixed with a standard name, so var item = item || 'hello' would have the RHS to be more intuitive and isolated from the actual variable name. As explained in the article , it might seem like a big load of nonsense, but I think It would be well worth the cause.

# Brandon Andrews (9 years ago)

Perhaps this proposal might fit with what you had in mind:

esdiscuss.org/topic/proposal-for-a-null-coalescing-operator

Been meaning to clean this up and submit it as an actual proposal since the idea is kind of simple:

sirisian/ecmascript