Extrange behaviour using "if XXX ..." and "XXX if ..."

Ruby
1

Hi, note the difference in those both cases:

a)
if a=“QWEQWE” : a end
=> “QWEQWE”

b)
a if a=“QWEQWE”
NameError: undefined local variable or method `a’ for main:Object

I know that the behaviour in a) is no recommended and maybe deprecated
in a
future, but why it works in a) and not in b) ?

Thanks.

2

Iñaki Baz C. wrote:

I know that the behaviour in a) is no recommended and maybe deprecated in a
future, but why it works in a) and not in b) ?

A method call without parentheses and a plain variable look the same, so
Ruby tries to determine between the two by looking for an assignment as
it parses your script. If it sees you assigning a value to “a”, then it
knows that “a” is a variable, otherwise it assumes that “a” is a method
call. Parsing occurs from the top down and from left to right.

In case (a) the assignment to “a” occurs before any other reference, so
Ruby knows it’s a variable.

In case (b), there has not yet been an assignment before the reference
to a, so Ruby assumes that “a” is a method call, yet there is no
definition for a so you get the message.

3

El Domingo, 30 de Marzo de 2008, Tim H. escribió:

In case (b), there has not yet been an assignment before the reference
to a, so Ruby assumes that “a” is a method call, yet there is no
definition for a so you get the message.

b)
a if a=“QWEQWE”
NameError: undefined local variable or method `a’ for main:Object

But why the first “a” is interpreted before the “if” stament? Imagine
this
example:

defined?a
=> nil
a=“BLABLA” if 2 == 3
=> nil
a
=> nil

After this code “a” will remain “nil” (or the previous value it had),
so:
a=“BLABLA”
hasn’t been interpreted since the “if” stament failed.

Also note this other example:

defined?kk
=> nil
kk if nil
=> nil

Why in this last case the code doesn’t return:
"undefined local variable or method kk’ "
?

I assume the reason: “kk” is not interpreted if the condition fails.
In b) the first “a” is then interpreted AFTER the condition success, so
in
that moment “a” has been already declared (into the condition), so it
would
exist and not give an error.

Am I not right?

4

El Domingo, 30 de Marzo de 2008, Tim H. escribió:

to the left of the assignment to a. When Ruby first encounters a
reference to a it assumes that since it has not yet seen any assigment
to a, then a must be a method name.

Ok, I understand. Thanks a lot.

5

Iñaki Baz C. wrote:

After this code “a” will remain “nil” (or the previous value it had), so:
Why in this last case the code doesn’t return:

You must distinguish between parsing and execution. Ruby parses your
program before Ruby executes your program.

Ruby decides how to interpret the reference to a during parsing, before
Ruby executes the if statements in your examples. Their success or
failure has nothing to do with the decision. In this case

a if a = “qweqwe”

Remember parsing occurs from left to right. Ruby sees the reference to a
to the left of the assignment to a. When Ruby first encounters a
reference to a it assumes that since it has not yet seen any assigment
to a, then a must be a method name.

6

Iñaki Baz C. [email protected] wrote:

Remember parsing occurs from left to right. Ruby sees the reference to a
to the left of the assignment to a. When Ruby first encounters a
reference to a it assumes that since it has not yet seen any assigment
to a, then a must be a method name.

Ok, I understand. Thanks a lot.

I asked the same question a few months ago, and got some great answers:

<http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/f03e
291e32ea2570/49ca1f19297bece6?lnk=st&q=#49ca1f19297bece6>

Understanding this point has been very useful to me subsequently…! m.

7

El Domingo, 30 de Marzo de 2008, matt neuburg
escribió:> I asked the same question a few months ago, and got some great answers:

<http://groups.google.com/group/comp.lang.ruby/browse_thread/thread/f03e
291e32ea2570/49ca1f19297bece6?lnk=st&q=#49ca1f19297bece6>

Understanding this point has been very useful to me subsequently…! m.

Thanks for the link matt,it’s very useful to understand this “issue”.

Regards.