Noob Q: ruby block scoping question (ruby TK)

ruby-talk
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 -----

···

--
Philip Amadeo Saeli
SUSE Linux 10.1
psaeli@zorodyne.com

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.)

···

--
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

3

* Joel VanderWerf <vjoel@path.berkeley.edu> [2008-04-30 20:17]:

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

···

--
Philip Amadeo Saeli
SUSE Linux 10.1
psaeli@zorodyne.com

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?

···

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

5

Albert Schlef wrote:

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?

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'
         }
}

···

--
       vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407