Talk Like A Duck: Tag metaprogramming

Block Your Privates!

Rick DeNatale — Tue, 04 Sep 2007 11:28:00 -0400

I’ve noticed that some rubyists like to use indentation to delineate method visibility.

The first time I noticed this was when Marcel Molina Jr. used it during the charity testing workshop at the Ruby Hoedown.. I just encountered it again in at least one piece of sample code from Rob Orsini’s “Rails Cookbook.”

During the testing workshop, Chad Fowler expressed displeasure with this style, and I’ve got to agree.

Here’s an example of this style:

class Gadget
  def framilize
    razzlitize if options[:secret_ingredient_6X]
  end

  private
    def razzlitize
    end
end

The problem is that the indentation is “artificial”, there really is no nesting of evaluation scope here. The way that Module#private and it’s kin work when they are called without arguments is to set a marker onto Ruby’s eval stack which gets popped when the current evaluation context is exitted. So the effects of the private method remain in effect until either the end of the current context, or one of the other methods like public or protected, whichever comes first. This means that if we extend the above example:

class Gadget
  #...
  private
    def razzlitize
    end

  def dazzlitize
  end
end

The indentation can trick us into thinking that dazzlitize is public when it’s really private.

I’d always found the nature of methods like private without arguments to be a minor annoyance with Ruby syntax. In my humble opinion they should have been able to take a block which delineated their effect. What if we could write:

class Gadget
  #...
  private do
    def razzlitize
    end
  end

  def dazzlitize
  end
end

Well, actually we can write that, but it doesn’t work as expected, since the block is silently ignored, and the method doesn’t even get defined.

So I started doing a little metaprogramming, to fix this. It seemed obvious how to do this. You alias_method Module#private so you can extend it, redefine the method to check for a block and if none is given, call the original method, otherwise evaluate the block in a way which makes any methods defined private. And of course you use test driven design to do this.

I made some progress but ran into some problems:

The obvious way to evaluate the block:
```
class module
  alias :old_private, :private
  def private(*args, &blk)
    if blk_given?
       module_eval do
         old_private
         blk.call
       end
    else
      old_private(*args)
    end
end
```
Doesn’t seem to work. The method isn’t made private. I had to resort to getting a list of the methods before the block, then calling old_private with the difference between the new methods after the block is evaluated, and those before.

The module_eval now looked something like this:
```
module_eval do
  existing = instance_methods(false)
  blk.call
  new_methods = instance_methods(false)-existing
  old_private(new_methods.map {|m| m.to_sym}
```
There are some obvious shortcomings in this code, but at this point, the goal was to do the simplest thing which could work for the test cases at hands, the complications would be dealt with later.
To add insult to injury, calling old_private from within the new definition doesn’t work either, the evaluation context gets marked as described above, but it gets popped off when we exit the context of the new definition. At this point I decided to punt, temporarily at least, and just define a new method Module#with_private which took a block, and leave the existing Module#private alone.
Then I decided that I should test changing the visibility of an existing method, in other words a test case like this:
```
class Test
  protected
  def meth;end
  with_private do
     def meth;end
  end
end
```
Test#meth should end up private, but my simple diff failed to notice the definition, things were starting to get more complicated. It looked like I’d need to hook Module#method_added and probably others. I began to wonder whether it was worth it.

Then I started to ponder the fact that the effect of private/protected/public gets popped when the evaluation context exits. So I said to myself, “Is there a way to take advantage of that?” Well, Virginia, yes there is.

class Gadget
  #...
  class_eval do
    private

    def razzlitize
    end

  end

  def dazzlitize
  end
end

This seems to work as expected, here’s a link to a test case file.

Now I still prefer being able to give a block to Module#private and it’s ilk, and I might still work on that, but in the meantime, class_eval and module_eval seem to provide a way to actually do what I want.

Time Flies While You're Having Fun Testing

Rick DeNatale — Wed, 18 Jul 2007 15:45:00 -0400

I’ve been working on adding support for localization of the user’s time zone on an existing Rails app for a client. In order to test this, I found myself building a time machine.

At first, I did a fairly simple hack which monkey patched the system methods Time.now, and Date.today. This worked until I got into some testcases of code which was triggered off of updated_at fields in various ActiveRecord models. Since I had to deal with these implicit dates, I found that I needed to have finer control than my simple patch gave.

The code has now evolved to the point where I think that it shows some interesting aspects of basic Ruby metaprogramming.

The Initial Approach

In order to control the time, I decided to add a module in Test::Unit::Testcase called TimeMachine, so that a testcase could just include TimeMachine when it needed the function.

The way it’s used is to write something like:

def testSomethingYesterday
   now_as(1.days.ago) do
     #code to be run yesterday here
   end
end

The now_as method takes a time as a parameter. Within the block, Time.now will return that time, and Date.today will return the date corresponding to that time.

Doing this was fairly straightforward. The method aliased the two methods, redefined them, then, within a begin block with an ensure clause to restore the methods afterwards, yielded to the block.

Non-stop Time Trip Only

While this simple approach worked well, it had one drawback. It couldn’t be stacked. If you called now_as again within the block, the inner call would remove the monkeypatched methods when it returned. This first showed up when I had a bug in one of my testcase methods. That was fixed easily enough by rewriting that test.

But when I ran into the code which was using implicit times, I figured it would be easier to make my test helper a bit more sophisticated. I needed a time machine which could make side-trips along it’s round, trip in time.

The TimeMachine as of Now

So here’s my current implementation of Test::Unit:Testcase::TimeMachine:

class Test::Unit::TestCase                    # 1
  module TimeMachine

    def now_as(time)
      time_class = class << Time; self; end   # 5
      date_class = class << Date; self; end
      begin
        Time.class_eval do 
          @now_stack ||= []
          if @now_stack.empty?                # 10
            time_class.class_eval do
              alias_method :old_now, :now
              def now
                @now_stack.last.dup
              end                             # 15
            end
            date_class.class_eval do
              alias_method :old_today, :today
              def today
                Time.now.to_date              # 20
              end
            end
          end
          @now_stack.push(time.dup)
        end                                   # 25 
        yield
      ensure
        Time.class_eval do 
          @now_stack.pop
          if @now_stack.empty?                # 30
            date_class.class_eval {alias_method :today, :old_today}
            time_class.class_eval {alias_method :now, :old_now}
          end
        end
      end                                     # 35
    end
end

The basic idea is to maintain a stack of times in a class instance variable of Time. We define the pseudo now and today methods when the first time is placed on this stack, and restore them when the last time is removed.

The tricky part of this code is knowing when to talk to the Time and Date classes and when to talk to their respective metaclasses. In lines 5 and 6 I grab the two metaclasses so that I can refer to them in the code below (DRY). In line 7 I start the begin block which ensures that things will be restored when now_as has finished.

On line 9, running in the context of the Time class, I ensure that it has an instance variable to contain the stack of now times. Then if the stack is empty, I define the methods. Lines 12-15 run in the context of Time’s metaclass to define now as a class method of Time. Lines 18-21 handle the today method in a similar fashion.

After we’ve ensured that our newly patched methods are there, we push the time on line 24.

The yield, on line 26 runs back in the context of the testcase, which proceeds to do it’s thing.

Once that’s done, succeed or not, the ensure block cleans things up. Lines 29-33 go back to the context of the Time class to manipulate the stack and, if it’s empty again, restore the original methods.

What’s in the Future?

So that’s where the time machine sits right now. It does the simplest thing that could possbily work, right now. It might be nice if it could, perhaps optionally, have the current time change rather than being fixed, in other words, Time.now would return the originally stated time plus whatever time increment had elapsed since the as_now call. But for now, I haven’t needed it, and I’m not planning to use the time machine to artifically skip ahead to find future requirements before I discover them in real time.

Postscript

After posting this yesterday, I discovered that the nesting didn’t really work. I was only pushing the time on to the stack the first time. I’ve just corrected the code above.