At RubyConf 2010 Shugo Maeda talked about Refinements: A proposal for a new feature in Ruby which allows you to easily override methods without affecting other parts of your program:
Let’s have a look at the why’s and how’s of this proposal.
The Power of Monkey Patching
Ruby allows you to both open previously defined classes and redefine any method. In addition, Ruby doesn’t treat core classes any differently from user-defined classes, so this gives you a lot of power to completely change the behaviour Ruby. This is of course a double edged sword: You can more easily change Ruby to match your thoughts (rather than changing your thoughts to match Ruby), but it also means that everyone else now needs to follow your rules.
Getting everyone to play along nicely has proven to be a challenge, and the solution has always been solved socially. As long as two core teams (let’s say Rails and DataMapper) work together, they can quite easily solve any problems, but the real issue is when you, as a user, want to use two libraries together. The libraries may work perfectly separately, but the moment you combine them you’ll get some weird behaviour. There’s not really much to can do, other than waiting for the library to be updated (or do the work yourself).
A wild Classbox appears!
If you’ve been following the development of Ruby, you may have heard of classboxes. They were first introduced by Alexandre Bergel, Stéphane Ducasse, and Roel Wuyts in 2003 by the paper Classboxes: A Minimal Module Model Supporting Local Rebinding. It’s essentially a way to monkey patch classes and methods, but only within the context of your code and not globally. At the moment, it’s been implemented in Smalltalk (Squak), Java and .Net, but there’s also been some work at trying to apply it to Ruby.
The refinements proposal by Shugo captures the same idea as classboxes, but it behaves slightly differently in certain cases (we’ll get back to those in a minute). The differences are not big enough to justify having both refinements and classboxes, so expect this to be the only way to safely monkey patch in Ruby in the following years (if the proposal gets accepted of course).
While this is still only a proposal, Shugo has actually implemented it in Ruby 1.9 and provided a patch, so why not install it right away so you can play with it as we go through the features?
$ curl -O http://stuff.judofyr.net/refinements.diff $ rvm install ruby-head-r29837 --patch refinements.diff $ rvm ruby-head-r29837
$ svn checkout -q -r 29837 http://svn.ruby-lang.org/repos/ruby/trunk ruby-refinements $ cd ruby-refinements $ curl http://stuff.judofyr.net/refinements.diff | patch -p1 $ autoconf $ ./configure --prefix /usr/local/ruby-refinements $ make $ make install $ export PATH="/usr/local/ruby-refinements/bin:$PATH"
Now you should be able to run all of the examples given in this article.
Refine, don’t redefine
Instead of redefining or defining new methods directly on classes, you’ll create refinements:
If you don’t do anything other than that, you won’t notice anything at all. However, now you can choose to use this refinement at many different scopes:
The great thing about refinements, is that it’s technically impossible to globally leak them. They will always be restricted to the scope you specify, and there’s nothing “above” the file scope.
That’s not always true though. Refinements are also enabled in subclasses and reopened classes, even if they are located in different files.
But here comes the best part: Refinements are also carried on in class_eval, module_eval and instance_eval:
Holy Schmoly, now we’re talking! Even this works as expected:
Refinements are also inherited, so Rails 4 could provide this module:
And because refinements are also enabled in subclasses:
You can continue developing in the exact same way as before, but now without leaking anything into the global namespace.
(This is the moment where you’re proposing to marry Shugo.)
What’s the catch?
There’s a few things you need to be aware of. First of all, there might be a little decrease in performance. Hopefully this will be resolved (or turn out to be insignificant) in the future. Other issues:
#include and #using are completely separated:
Because refinements are lexically scoped, it’s also not possible to combine them with an included hook:
You can however use the used hook:
Singleton methods in refinements are not included:
You can’t refine modules:
Refinements don’t have local rebinding
Another important fact is that, unlike classboxes, refinements don’t have local rebinding. Let me show you an example:
At first, it might seem counter-intuitive. Why does the last line prints a list of integers? Why isn’t the refinement enabled in that method? As you might have guessed, it’s because refinements don’t have local rebinding. This means that the refinements will only apply to the scope they are enabled. The moment you call a method outside of the scope, none of the refinements apply anymore.
The advantage of this is that you can safely override methods without thinking about breaking anything else. You simply can’t refine code in another scope. However, there’s a huge disadvantage: If there’s a “core” method (like #each above) which is used by several other methods, you can’t affect the other methods.
Local rebinding might be implemented, but in that case, refinements will be renamed to classbox (since that’s what they are).
As I’ve mentioned earlier, there is currently a patch available that builds cleanly on top of r29837. There are some implementation details which might need to be resolved, but as far as I know, both matz and ko1 are positive for merging the patch.
Refinements are very much a work in progress, so if you have any more details or questions about how they work, feel free to contact me on firstname.lastname@example.org so I can keep this article up to date.