ejdraper.com

What’s up Proc?

So it’s awesome Ruby snippet time, and in particular I’m going to look at the ability to evaluate statements against a block, specifically to find out where the particular block came from.

The “eval” command not only takes in the command to be executed, but can also optionally take in a binding to run against. This means that instead of evaluating a command against the current, local binding, a specific binding can be used, and for our example, we are going to use the binding on a Proc object, to allow us to evaluate a statement as if it was running within the block itself.

Let’s setup a module that allows us simply to register a block to an array:

module TestApp
  class << self
    # Adds a block to our global array
    def add_block(&block)
      @@blocks ||= []
      @@blocks << block
    end

    # This just returns our block array so we can iterate through it
    def blocks
      @@blocks
    end
  end
end

Within this same file (let’s call it test1.rb), we can also register a test block. The execution of the block isn’t really important, so let’s just do:

TestApp::add_block { puts "test1" }

Now let’s setup a second script (called test2.rb) that’ll also register a block, and that will iterate through the blocks and use the “eval” command to show where each block originated from:

# Reference our first script
require File.join(File.dirname(__FILE__), "test1")

# Add a second block
TestApp::add_block { puts "test2" }

# For each block we have, run a statement that will return the "__FILE__"
# variable for each block, against the blocks own binding
TestApp::blocks.each do |blk|
  puts "Block from: #{eval('__FILE__', blk.binding)}" 
end

If we run the test2.rb script now, we should see output similar to the following:

Block from: ./test1.rb
Block from: test2.rb

So we can now differentiate between our blocks, by investigating the blocks own binding! Something to bear in mind is that obviously the paths shown are relative – if you were executing the test2.rb script using an absolute path (for example, “ruby /path/to/test2.rb”), you’d see that the absolute paths were shown instead. Either way, the information should be useful in determining the origin of a block.

Now you may be asking, what’s the use case for something like this? Our block registration code above does nothing useful, and in fact we don’t even execute the blocks themselves! Well, within Feather we use this code to find out which plugin registered a particular block – in this way, we can check at runtime (before executing the registered block) whether the plugin is active or not. If it isn’t, it won’t be executed, if it is, it will.

This is just one of those cool things you can do when you have a reference to a specific binding – there’d be nothing to stop you from interacting with the blocks bindings in other ways too.