Ruby modules, the template pattern, and dynamic closure application

This post demonstrates how to apply a set of closures to various components (i.e. Ruby on Rails controllers) in a very flexible, indirect, and dynamic fashion. The final result involves using modules to implement a template pattern and invoking closures bound to new contexts.

Abusing Kernel#caller (remembering Java Reflection)

I recently had an issue where I needed to know the caller of a method. The goal was to apply one or more closures cached in a singleton configuration object to a controller or other component. I was originally on the right track, but I got sidetracked by a google search. I was reminded of Kernel#caller. The mess that ensued looked like this:

 1 require 'active_support/inflector'
 3 module Arbitrary2
 4   class MyController
 6     def some_action
 7       NeedsToKnowCaller.apply_config
 8     end
10   end
11 end
13 module NeedsToKnowCaller
15   SIG = /controllers\/([^\.]*).*`([^']*)'/
17   class << self
19     # overriding Kernel#caller only for sake of repeatability on blog
20     # during normal use this override would not exist
21     def caller
22       ["/arbitrary/project/app/controllers/arbitrary2/my_controller.rb:20:in `some_action'"]
23     end
25     # extract signature for use elsewhere...
26     # dont want to explicitly declare caller as a param but could...
27     def apply_config
28       md = caller[0].match(SIG)
29       sig = "#{md[1].classify}.#{md[2]}"
30       # could do something with eval here... timeout...
31       puts sig
32     end
34   end
35 end
38 # printed value is "Arbitrary2::MyController.some_action"

What happens here is that some_action is called in an instance of MyController. This calls apply_config in the NeedsToKnowCaller module which is able to look up the class that called it. This implementation is left incomplete. It is not at all a dead end, but it is an expensive and unnecessary bad road to continue down.

Ruby Modules and the Template Design Pattern

As soon as I was finished tracking down the caller I remembered what I was really trying to do in the first place. I did not just need the name of the caller. I needed the context of the caller as well so that I could invoke a closure in the context of the caller. The solution above is terrible. I blame my history with Java reflection for this brief lapse of judgement. For anyone looking up Kernel#caller or a regex to be used with it, please stop right here. Ruby has better options in the form of modules.

Modules can be used for much more than just bags of functions or namespaces. The template pattern typically looks a little different than this, but that is essentially what I ended up reinventing. Instead of using inheritance, I ended up using mixins in a slightly different way than I usually do.

 1 module NeedsToKnowCaller
 3   class << self
 5     # actual impl much more complex...
 6     def config(key)
 7       # hard coded for clarity
 8       -> { root_path }
 9     end
11     def apply_config_to _caller, key
12       _caller.instance_exec &config(key)
13     end
15   end
17   module ControllerMethods
19     # dont want to explicitly declare caller as a param but could...
20     def apply_config(key)
21        NeedsToKnowCaller.apply_config_to self, key
22     end
24   end
26 end
28 module Arbitrary2
29   class MyController
30     include NeedsToKnowCaller::ControllerMethods
32     def some_action
33       apply_config :varies
34     end
36     def root_path
37       "would normally come from rails routing"
38     end
39   end
40 end
43 # => "would normally come from rails routing" 

In this example, any controller that includes NeedsToKnowCaller::ControllerMethods will be able to call NeedsToKnowCaller.apply_config_to(self) with just apply_config. Apply_config_to will then call config which returns a lambda which is invoked in the context of the instance that was passed into apply_config_to. So an instance of MyController calls apply_config which indirectly calls root_path. The config method in my actual implementation is much more involved.

This example might suffer from oversimplification. In the context of a large project, small details like cutting a derivable parameter out of a method can be really helpful. In a small project this wouldn't make much sense.

What I do find interesting is how well Ruby facilitates some older design patterns. I learned the template pattern with Java. In my experience it always looks the same in Java. A subclass adds something around a superclass method. Here a collection of semi-related classes call another singleton class that is not inherited at all. The idea is the same. The implementation is totally different. Furthermore, the ease with which closures can be reapplied to other contexts is extremely powerful.

comments powered by Disqus