Can a variable be changed within a block? - ruby

Question

Let's go to the code directly:
#!/usr/bin/ruby
require 'tk'
class Epg
def initialize
#var = "bad"
#cvs = nil
#items_demo = TkRoot.new() {title "EPG"}
TkFrame.new(#items_demo) {|cf|
#var = "good"
#cvs = TkCanvas.new(cf) {|c|}
puts "#cvs 1 is #{#cvs}"
puts "#var 1 is #{#var}"
}.pack('side'=>'top', 'fill'=>'both', 'expand'=>'yes')
puts "#cvs 2 is #{#cvs}"
puts "#var 2 is #{#var}"
end #initialize
def test
#var = "bad"
puts " #var 3 :#{#var}"
(1..3).each {|x| #var="good"}
puts " #var 4 :#{#var}"
end
end
e= Epg.new
e.test
Here is the output:
#cvs 1 is #<Tk::Canvas:0xb7cecb08>
#var 1 is good
#cvs 2 is
#var 2 is bad ##var has NOT been changed by the code in the block
#var 3 :bad
#var 4 :good ##var has been changed by the code in the block
Why we see different behavior here?

Answer 1

You can think of blocks as closing over both the set of local variables and the current self.
In Ruby, you will always have access to local variables, no matter what. The self encapsulates instance methods on the current object as well as instance variables.
Consider the following code:
class Table
def initialize(legs)
#legs = legs
end
def with_legs
yield #legs
end
end
And then:
def some_calling_method
name = "Yehuda"
Table.new(4) {|legs| puts "#{name} gnaws off one of the #{legs} legs" }
end
By Ruby's block semantics, you can be assured that name will be available inside the block, even without looking at the method you're calling.
However, consider the following:
class Person
def initialize(name)
#name = name
end
def gnaw
Table.new(4).with_legs do |legs|
puts "#{#name} gnaws off one of the #{legs} legs"
end
end
end
Person.new("Yehuda").gnaw
In this case, we are accessing the #name instance variable from inside the block. It works great in this case, but is not guaranteed. What if we implemented table a bit differently:
class Table
def initialize(legs)
#legs = legs
end
def with_legs(&block)
self.instance_eval(&block)
end
end
Effectively, what we're saying is "evaluate the block in the context of a different self." In this case, we are evaluating the block in the context of the table. Why would you do that?
class Leg
attr_accessor :number
def initialize(number)
#number = number
end
end
class Table
def initialize(legs)
#legs = legs
end
def with_leg(&block)
Leg.new(rand(#legs).instance_eval(&block)
end
end
Now, you could do:
class Person
def initialize(name)
#name = name
end
def gnaw
Table.new(4).with_leg do
puts "I'm gnawing off one of leg #{number}"
end
end
end
If you wanted access to the person object inside of the block, you'd have to do:
class Person
def initialize(name)
#name = name
end
def gnaw
my_name = name
Table.new(4).with_leg do
puts "#{my_name} is gnawing off one of leg #{number}"
end
end
end
As you can see, the use of instance_eval can make it simpler and less bulky to access methods of a far-off object inside a block, but comes at the cost of making the self unaccessible. The technique is usually used in DSLs, where a number of methods are injected into the block, but the self doesn't matter that much.
This is what's happening with Tk; they're using instance_eval to inject their own self into the block, which is wiping your self clean.

Answer 2

The explanation is that TkFrame.new uses instance_eval and thus the assignment #var = "good" changes the instance variable of TkFrame. Try this out:
class A
def initialize(&b)
instance_eval(&b)
end
end
class B
def initialize
#x = 10
#a = A.new do
#x = 20
end
end
end
p B.new
This is what you'll see:
#<B:0x10141314 #x=10, #a=#<A:0x10141300 #x=20>>