Question

IRB is a nice way to play around and test things in Ruby. It’s also possible to do some setup using a script, like this:

require 'irb'

class Pirate
  def greet
    puts "Arrrrr, nice to meet ya"
  end
end

IRB.start # You can now instantiate Pirate in IRB

One thing I’m unclear on, however, is variable scope when doing this. If I add these lines before IRB.start:

smithy     = Pirate.new
@blackbard = Pirate.new

… @blackbeard will be available in IRB, but referencing smithy will get undefined local variable or method 'smithy' for main:Object.

Why?

Answer 1

The Binding that is used to evaluate the code is set up in irb/workspace.rb:51 (I’m referring to Ruby 1.9.3 rev 35410 here):

@binding = eval("def irb_binding; binding; end; irb_binding",
                TOPLEVEL_BINDING,
                __FILE__,
                __LINE__ - 3)

That means that your IRB session runs in the same context as code inside a top-level method. Observe:

puts "Outer object ID: %d" % self.object_id
puts "Outer binding: " + binding.inspect
smithy     = Pirate.new
@blackbard = Pirate.new

def test
  puts "Inner object ID: %d" % self.object_id
  puts "Inner binding: " + binding.inspect
  p @blackbard
  p smithy
end
test

Output:

Outer object ID: 13230960
Outer binding: #<Binding:0x00000001c9aee0>
Inner object ID: 13230960
Inner binding: #<Binding:0x00000001c9acd8>
#<Pirate:0x00000001c9ada0>
/test.rb:18:in `test': undefined local variable or method `smithy' for main:Object (NameError)
    ...

Note that the object context (self) is the same both inside and outside the function. This is because every top-level method is added to the global main object.

Also note that the bindings inside and outside of the method differ. In Ruby, every method has its own name scope. This is why you can’t access the local name from inside IRB, while you can access the instance variable.

To be honest, IRB is not the most glorious piece of Ruby software. I usually use Pry for this kind of stuff, using which you can just do:

require 'pry'
binding.pry

And have a session with access to the current local variables.