3 ms·

It seems like this thread has gone several different directions. Surely suggesting that that (null>0) should return null or undefined is a separate topic from s

It seems like this thread has gone several different directions. Surely suggesting that that (null>0) should return null or undefined is a separate topic from suggesting that if() statements have three different control branches? FWIW, I totally buy the former. If (null>0) returned null, then most things would still work as expected, and you could easily check the result of the comparison to catch unintended behavior. One can easily imagine a world where JS was defined this way from the start, and it'd be pretty much the same language. The latter (three-way IF control structures) strikes me as waaaay more tenuous - much bigger change, more complexity on the programmer, and no benefits I can see that you wouldn't get from the former bit.

lisper 9y ago
The reason for the three-way IF would be to avoid conflating null and false. Without that you'd have to write: IF (x<y)==null { [otherwise] } ELSE IF (x<y) { [then] } ELSE { [else] } That seems awkward to me.
- fenomas 9y ago
  Yeah, I get that that's the intent, but (per my original comment) I'd think it would surely create more mess than it cleans up. For example, I suspect that three-way IFs like you describe would only really get used in two ways - often the second and third branches would be identical, and the rest of the time the third branch will be some kind of "console.warn('bad inputs!')" kind of error handling. For the latter of those two cases, testing for the error case before proceeding to the regular logic (as in your code sample above) seems intuitively like the right thing to do - analogously to how you might check (isNaN(operand)) before doing some math. And in the former case, if the second and third branches are identical you'd almost certainly want some syntactic sugar to avoid writing the same logic twice, like "IF (bool) {...} ELSE-AND-OTHERWISE {...}" -- which would just be isomorphic to what we have now. You know what I mean?

lisper 9y ago

The reason for the three-way IF would be to avoid conflating null and false. Without that you'd have to write: IF (x<y)==null { [otherwise] } ELSE IF (x<y) { [then] } ELSE { [else] } That seems awkward to me.

fenomas 9y ago
Yeah, I get that that's the intent, but (per my original comment) I'd think it would surely create more mess than it cleans up. For example, I suspect that three-way IFs like you describe would only really get used in two ways - often the second and third branches would be identical, and the rest of the time the third branch will be some kind of "console.warn('bad inputs!')" kind of error handling. For the latter of those two cases, testing for the error case before proceeding to the regular logic (as in your code sample above) seems intuitively like the right thing to do - analogously to how you might check (isNaN(operand)) before doing some math. And in the former case, if the second and third branches are identical you'd almost certainly want some syntactic sugar to avoid writing the same logic twice, like "IF (bool) {...} ELSE-AND-OTHERWISE {...}" -- which would just be isomorphic to what we have now. You know what I mean?