Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language

Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

Ruby Programming Language

bug in ruby

class Foo
  attr_accessor :bar

  def foo
    self.bar = 1

    if false
      bar = 2        # never executed

    p self.bar       # prints 1
    p bar            # prints nil

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

Hi --

That's not a bug.  The parser sees:

   bar = 2

and that triggers the allocation of bar.  Since the expression is
inside of the if false block, it never gets executed, so bar is nil.


Q. What is THE Ruby book for Rails developers?
A. RUBY FOR RAILS by David A. Black (http://www.manning.com/black)
    (See what readers are saying!  http://www.rubypal.com/r4rrevs.pdf)
Q. Where can I get Ruby/Rails on-site training, consulting, coaching?
A. Ruby Power and Light, LLC (http://www.rubypal.com)

Sorry - where's the bug?  You think the

p bar

should give 1?  I believe you are thinking of

p @bar ??

Or have I - as I often do - missed the point? =)

sairam MP wrote:
>     if false
>       bar = 2        # never executed
>     end

There is no way that this conditional will be triggered.

if expr

will only execute the body of the if statement if expr is true. False is
never true (outside of politics), hence it is never executed.

This is a bug in your understanding of the language, not in the language
itself. You've not said exactly what you think it *should* do instead of
what it does, so it's hard to give an answer tailored to improving your

But briefly: an assignment like "bar = 2" is seen at the time the program is
*parsed* and means that an unqualified "bar" is treated as a local variable
from that point onwards until the end of that scope. Whether or not it is
actually *executed* makes no difference.

When you write "self.bar" or "self.bar=" you are explicitly making a method
call to a method "bar" or "bar=" on the current object; this is never
treated as a local variable.

If you write "bar" by itself, this is treated as a method call on the
current object *unless* an assignment of the form "bar = x" has been seen by
the parser earlier in the scope.



--- sairam MP <sai@gmail.com> wrote:

___________________________________________________________________________ _________Luggage? GPS? Comic books?
Check out fitting gifts for grads at Yahoo! Search
On 22.05.2007 14:53, Brian Candler wrote:

Additional reference material:


Kind regards


On 5/22/07, sairam MP <sai@gmail.com> wrote:

[ snip ]

A gentle suggestion:

"Don't claim that you have found a bug"


Robert Klemme schrieb:

It should be added in the documentation, that such an uninitialized local
variable is set to the initial value "nil".

Wolfgang Ndasi-Donner

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc