Noob Q: ruby block scoping question (ruby TK)

Ruby
1

I’ve just recently been getting to know ruby and the ruby Tk library and
have run into a block scoping problem [apparently] that I don’t really
understand (I’m a long-time C programmer, mostly at the systems and
library levels, and have little experience with VHLLs such as ruby).

I’ve included below a cobbled up example that demonstrates the problem
that has been driving me completely batty.

Basically, why is the “mybutton” method reference not contained within
the binding of the block passed to the TkButton.new method though it is
clearly within the scope of the initialize_n methods?

I guess my question boils down to is how much of the block’s context is
actually contained within its binding, i.e., how far out does it extend?
Obviously, it extends at least to that of the method within which it
appears. Why not to all symbols visible within the class definition
(as, apparently, it doesn’t)?

I do realize that the actual block passed to the “command” method in the
outer block passed to the TkButton.new method is actually executed in
the context of the button code itself somewhere in the Tk library and,
therefore, executes in -that- context. However, it’s binding should
carry over some of the context in which it was created. How much (i.e.,
to what extent)?

Any references to books, online docs, code examples, ruby interpreter
sources, etc., in this regard would also be much appreciated.
Additionally, any insights as to what goes on “behind the scenes” in
ruby would be very helpful.

Thanks!

Phil

----- Begin ruby code -----
#!/usr/bin/ruby -w

require ‘tk’

class MyButton

def myexit
exit
end

Doesn’t work: “myexit” out of scope in block. Why?

def initialize_1
mybutton = TkButton.new do
text “EXIT”
command { myexit }
pack
end
end

Works: refs “myexit” outside of block.

Note that “myexit” -is- visible within the initialize_2 method!?!

def initialize_2
mybutton = TkButton.new do
text “EXIT”
pack
end
mybutton.command { myexit }
end

Works: creates local proc object to pass to block.

Note that “myexit” -is- visible within the initialize_3 method!?!

def initialize_3
proc_myexit = lambda { myexit }
mybutton = TkButton.new do
text “EXIT”
command proc_myexit
pack
end
end

Pick one of “initialize_[123]” to perform the test cases.

def initialize
initialize_1
#initialize_2
#initialize_3
Tk.mainloop
end
end

MyButton.new
----- End Ruby Code -----

2

Philip Amadeo Saeli wrote:

I’ve just recently been getting to know ruby and the ruby Tk library and
have run into a block scoping problem [apparently] that I don’t really
understand (I’m a long-time C programmer, mostly at the systems and
library levels, and have little experience with VHLLs such as ruby).

That’s a really good question.

It’s because of #instance_eval. The blocks you pass to Tk tend to get
treated like this:

tkobject.instance_eval(&your_block)

So all the instance variables and methods in your_block become scoped to
tkobject. IMO, this was initially a very popular way of structuring a
ruby lib API which has since become less popular. (Anyway, I’m less fond
of it than I once was.) It is now more common for a #new method to yield
the instance being constructed to the block. Nothing funny happens to
the block scope, but you have to refer to the instance as the explicit
receiver of messages.

To emulate this kind of API with Tk, I tend to use the following
construct:

class Object
unless method_defined?(:then)
# Workaround for tk’s instance_eval-ed blocks.
def then
yield(self)
self
end
end
end

This allows you to do:

 @btn = TkButton.new(btn_frame).then { |w|
   w.text "My Button"      # w must be referred to explicitly
   w.background get_color  # calls method in expected scope
   w.state 'normal'
   w.command proc {
     @btn.configure 'state'=>'disabled'
                           # @btn has expected scope
   }
   w.pack('side'=>'left', 'padx'=>10, 'pady'=>10)
 }

This is, however, a matter of taste. (Also, I think other people call
#then by a different name, like #tee or something.)

3

It’s because of #instance_eval. The blocks you pass to Tk tend to get
treated like this:

tkobject.instance_eval(&your_block)

Thanks, Joel! You gave me just what I needed to begin to understand
this. Looking thru ruby-talk, it seems that instance_eval has been the
source of quite a few questions in similar regards!

Phil

4

Joel VanderWerf wrote:

 @btn = TkButton.new(btn_frame).then { |w|
   w.text "My Button"      # w must be referred to explicitly
   w.background get_color  # calls method in expected scope
   w.state 'normal'
   w.command proc {
     @btn.configure 'state'=>'disabled'
                           # @btn has expected scope
   }
   w.pack('side'=>'left', 'padx'=>10, 'pady'=>10)
 }

Is it possible to do ‘w.configure …’ instead of ‘@btn.configure …’?
Why did you choose the latter?

5

Albert S. wrote:

 }

Is it possible to do ‘w.configure …’ instead of ‘@btn.configure …’?
Why did you choose the latter?

Sorry, bad example. Thanks for pointing that out. It should really be w.

I was trying to show that you can refer to instance variables of the
same instance as in the outer scope. So, for example, if you had another
button that was disabled by pressing this one, you might express that
as:

@btn2 = …
@btn1 = TkButton.new(btn_frame).then { |w|
w.command proc {
@btn2.configure ‘state’=>‘disabled’
}
}