evenstensberg at gmail.com (2016-04-17T19:51:02.326Z)
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.evenstensberg at gmail.com (2016-04-17T19:48:00.329Z)
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.evenstensberg at gmail.com (2016-04-17T19:47:23.373Z)
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'
}`
This might be a duplicate of what someone else have already said though.
`function() {
var false = false
evalToTrue()
// outputs the value of false
}`
`evalToTrue()` here means the XOR calculation.evenstensberg at gmail.com (2016-04-17T19:43:49.986Z)
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.
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. On Sun, Apr 17, 2016 at 6:30 PM, Jordan Harband <ljharb at gmail.com> wrote: > This has been discussed many times before: > - https://esdiscuss.org/topic/operators-and > - https://esdiscuss.org/topic/logical-assignment-operators > - https://esdiscuss.org/topic/is-much-needed > - https://esdiscuss.org/topic/please-add-orequal-operator > > 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. > > On Sun, Apr 17, 2016 at 6:21 AM, even stensberg <evenstensberg at gmail.com> > wrote: > >> 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 - long & !clean codelines >> -default params (ES) , though it won't be a general use case >> >> There is already a lot of assignment, string and so on operators, but I >> don't really seem any of them touch this, except maybe the bit-wise OR >> assignment Operator. To read more about that, check these two links out: >> >> https://msdn.microsoft.com/en-us/library/81bads72(v=vs.94).aspx >> http://web.eecs.umich.edu/~bartlett/jsops.html >> http://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 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 more clean and it makes sense. >> JavaScript teaches us and wants us to use `+ =`,` - =` and any other >> type of "abbreviation" , so this makes perfectly sense for me. Either I'm >> crazy, but it seems like this should have been implemented a long time ago. >> ( Perhaps I'm both). >> >> 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. >> >> _______________________________________________ >> es-discuss mailing list >> es-discuss at mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20160417/6219d4b0/attachment.html>