You can force it into one line in various ways if that’s what you
want. For example:
if a=foo then return a; end
Or if you want something more arbitrarily idiomatic you could use
something like:
(a = foo) && (return a)
However that’s pretty ugly. If you want human-parseable code you’re
probably better off with something like:
def get_something
# …
if most_likely_answer = foo
return most_likely_answer
end
# … more expensive tests
end
…because at least then it’s clear why you’re making the
short-circuit branch. And if you want to use the result of foo
after the if-branch it’s definitely clearer if you do the assignment
explicitly beforehand:
def get_something
# …
possible_answer = foo
# …
if possible_answer
return possible_answer
end
# …
possible_answer += 7
end
The reason return a if a=foo doesn’t work is because of scope. I
looked it up once many moons ago but can’t remember the details
anymore. Perhaps someone who understands the parse tree can help.
The expression after an IF does not define new scope, you’re still in
the containing scope. This means the initial statement of the
if-modifier is validating the scope of any local variables before the
if-modifier expression is evaluated.
According to the “Ruby Standardization WG Draft August 25, 2010”
Section 12.3 The if modifier statement
Page 107
Semantics
An if-modifier-statement of the form S if E, where S is the statement
and E is the expression,
is evaluated as follows:
a) Evaluate the if-expression of the form if E then S end.
b) The value of the if-modifier-statement is the resulting value.
The Semantics section item ‘a’ clearly states that the if-modifier
should be interpreted in the same manner as the equivalent single-line
if-expression. This means that the initial statement should not be
validating local variables until after the modifier expression is
evaluated, possibly initializing new local variables for use in the
initial statement.
No. Local variables are defined from the location of their first
assignment. Since the assignment comes lexically after the test the
variable is undefined in the expression. That’s actually a pretty
well known property of the language - albeit a bit tricky at times.
An if-modifier-statement of the form S if E, where S is the statement
evaluated, possibly initializing new local variables for use in the
initial statement.
You are missing an important detail: local variable definition is done
at parse time. It is purely syntactical and has nothing to do with
runtime evaluation. What you call “validation of local variables” at
runtime does not exist.
Please report this as an interpretor bug.
Please don’t.
We’re lucky because there is another idiom which fits the bill (I
won’t go into lengthy explanations why I still consider assignments in
conditionals bad and only reasonable in loops):
r = foo and return r
Hint: different precedence of “and” compared to “&&” makes this
possible without the brackets that Matthew hat to use.
is good, but i think i’ll stick w the older if r=foo style…(in the meantime
I wouldn’t do that, there is a certain risk that it looks like a
typing error (i.e. someone assumes you meant “if r==foo…”). If I
would want to use “if” then I’d do
I wouldn’t do that, there is a certain risk that it looks like a
typing error (i.e. someone assumes you meant “if r==foo…”)
Clear documentation and commenting can help there.
But I think the idiom with “and” is superior.
It’s concise, but it’s a very idiomatic idiom. At a glance it’s
harder to understand than the ‘if r=foo…’ construct (which is also
idiomatic). If you use it in all your code, however, I won’t
complain.
On Fri, May 25, 2012 at 3:57 AM, Matthew K. [email protected]
wrote:
On 25 May 2012 01:14, Robert K. wrote:
On Thu, May 24, 2012 at 4:50 PM, botp wrote:
I wouldn’t do that, there is a certain risk that it looks like a
typing error (i.e. someone assumes you meant “if r==foo…”)
Clear documentation and commenting can help there.
But where is the point in searching for a short, concise idiom and
which then needs added documentation to avoid errors?
But I think the idiom with “and” is superior.
It’s concise, but it’s a very idiomatic idiom. At a glance it’s
harder to understand than the ‘if r=foo…’ construct (which is also
idiomatic). If you use it in all your code, however, I won’t
complain.
I would actually consider it an advantage if it stands out so much as
strange: that way you do not glance over it easily (what might happen
with “if r=foo”) and if you do not know it you’ll soon find out.