Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
BrianTMaurer opened this issue Nov 29, 2014 · 6 comments
Open

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

BrianTMaurer opened this issue Nov 29, 2014 · 6 comments

Comments

@BrianTMaurer
Copy link

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

@mationai
Copy link

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
Copy link
Collaborator

Namek commented Nov 29, 2014

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
Copy link

nmussy commented Nov 29, 2014

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
Copy link

nmn commented Dec 1, 2014

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
Copy link
Contributor

Please no, not lua.

@nmn
Copy link

nmn commented Dec 5, 2014

@zekesonxx Please elaborate a little.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants