Proposal: if <expr> then <expr> else <expr>

[BrianTMaurer]

To improve "natural" left-to-right readability I would love to see if <expr> then <expr> else <expr>; expressions.

[fuzzthink]

Agree. Even as a long time pythonist, python's way always feels backwards to me; it goes against every single language's ternary flow and doesn't read as well.

[fuzzthink]

Agree. Even as a long time pythonist, python's way always feels backwards to me; it goes against every single language's ternary flow and doesn't read as well.

[Namek]

TL;DR; I'm not sure. BUT!...

It depends how you look at it. Let's get rid of "else ". Then let's compare this (oh dear gamedev):
if isCardBonusable(card) then Bonus.create(...)
to this:
Bonus.create(...) if isCardBonusable(card)

NOW let's assume that you read from left to right. First what you can see in second example is Bonus.create(...). And what is this? The default expected value. That's what you're most interested in. Little less interesting is when it's Bonus.create(...) so in second place we can see if isCardBonusable(card). The effect is that you don't have (by reading left-to-right) to read and understand whole line, while in the first example - you do. Second one wins.

But to be authentic myself, I noticed that it's like fighting with stupid habits. And behaviour "I like it better because I've seen it first in my life" is a stupid habit. So let's go back to me being authentic - years ago I would agree with @BrianTMaurer and @fuzzthink. Now I'm not sure.

To see it more alive.

Some other example (taken from WebSocket implementation in ActionScript):

return header.length == 2 ? {
    name: header[0],
    value: header[1]
} : null;

return {
    name: header[0],
    value: header[1]
} if header.length == 2;

What's more important? Condition or returning value?

And the last short comparison:
var bonus = Bonus.create(...) if isCardBonusable(card);
vs
var bonus = if isCardBonusable(card) then Bonus.create(...);

which is better and why? You know my arguments.

[Namek]

TL;DR; I'm not sure. BUT!...

It depends how you look at it. Let's get rid of "else ". Then let's compare this (oh dear gamedev):
if isCardBonusable(card) then Bonus.create(...)
to this:
Bonus.create(...) if isCardBonusable(card)

NOW let's assume that you read from left to right. First what you can see in second example is Bonus.create(...). And what is this? The default expected value. That's what you're most interested in. Little less interesting is when it's Bonus.create(...) so in second place we can see if isCardBonusable(card). The effect is that you don't have (by reading left-to-right) to read and understand whole line, while in the first example - you do. Second one wins.

But to be authentic myself, I noticed that it's like fighting with stupid habits. And behaviour "I like it better because I've seen it first in my life" is a stupid habit. So let's go back to me being authentic - years ago I would agree with @BrianTMaurer and @fuzzthink. Now I'm not sure.

To see it more alive.

Some other example (taken from WebSocket implementation in ActionScript):

return header.length == 2 ? {
    name: header[0],
    value: header[1]
} : null;

return {
    name: header[0],
    value: header[1]
} if header.length == 2;

What's more important? Condition or returning value?

And the last short comparison:
var bonus = Bonus.create(...) if isCardBonusable(card);
vs
var bonus = if isCardBonusable(card) then Bonus.create(...);

which is better and why? You know my arguments.

[nmussy]

While I agree that it's a familiarity issue, the if <cond> then <expr> vs. <expr> if <cond> is a case of what the interpreter reads vs. what I want it to do.

if blocks aren't parsed if the condition isn't met, whilst the <expr> if <cond> reads like "Okay, now I do that... oh, wait, never mind." I don't think JavaScript or Spider are high level enough for us to detach ourselves from the way they will be interpreted, if that makes any sense.

[nmussy]

While I agree that it's a familiarity issue, the if <cond> then <expr> vs. <expr> if <cond> is a case of what the interpreter reads vs. what I want it to do.

if blocks aren't parsed if the condition isn't met, whilst the <expr> if <cond> reads like "Okay, now I do that... oh, wait, never mind." I don't think JavaScript or Spider are high level enough for us to detach ourselves from the way they will be interpreted, if that makes any sense.

[nmn]

My opinion on this is that familiarity with the JS should be preferred in all cases. In this case, JS has no similar feature any way.

[nmn]

My opinion on this is that familiarity with the JS should be preferred in all cases. In this case, JS has no similar feature any way.

[zekesonxx]

Please no, not lua.

[zekesonxx]

Please no, not lua.

[nmn]

@zekesonxx Please elaborate a little.

[nmn]

@zekesonxx Please elaborate a little.