From: Igor Pirnovar <lists@...>
Date: 2012-11-04T20:16:20+09:00
Subject: Re: bug?: local variable created in if modifier not available in modified expression

Brian Candler wrote in post #1082725:

>>> def bar
>>>   "Method bar"
>>> end
> => nil
>>> bar if bar = 123
> (irb):4: warning: found = in conditional, should be ==
> => "Method bar"

You are misleading us here with {{ def bar; "Method bar"; end }} before
the assignment in {{ bar if bar = 123 }}, because parser now thinks that
it sees the method bar. Try it with a new variable, that is not shadowed
by another token like in your case the bar method, and you will see,
that interpreter exits with the error! For instance:

   p "v5:#{v5 if ((v5='created')!='')}"  #=> FAILS with:
    # t.rb:28:in `<main>': undefined local variable \
    # or method `v5' for main:Object (NameError)

> ... There are no "static variables" or "dynamic variables" in Ruby.
> Neither does operator precedence have anything to do with this.

I completely agree with the part stating there are no static or dynamic
variables. I used the terminology above to disprove what the author of
this thread suggested, namely that with respect to local vars Ruby acts
as a statically typed language. I showed that even if for the sake of
the argument we accept his suggestion, it can be proved that variables
spring into existence as soon as they are assigned a value, and are
visible inside their scope exactly as expected.

Precedence may not be important, though I am not sure it is not, since
the run-time must wait for the condition to be evaluated, therefore  it
will execute the assignment inside the 'if' expression in accordance
with precedence, namely prior 'if' expression itself is evaluated, hence
allowing the evaluation of the expression in front of the conditional,
the run-time was waiting for.

Also, the fact that {{ puts var||='n/a' if var=123 }} works as expected,
and {{ puts var if var=123 }} does not, proves that evaluation here is
right-to-left regardless of the fact that parser works in the opposite
direction, after all, if parser would react to the first assignment it
encountered in 'strictly' left-to-right fashion the result should be
'n/a' and not 123 that was evaluated last.

Regards, igor

-- 
Posted via http://www.ruby-forum.com/.