Happy Friday! It’s Rails 3.2 day! The official release announcement mentions a few of the big changes, but I’d like to take a moment to highlight a relatively small change I was responsible for, one that I hope may make your life a little easier.
From the ActiveRecord CHANGELOG:
Generated association methods are created within a separate module to allow overriding and
composition using `super`. For a class named `MyModel`, the module is named
`MyModel::GeneratedFeatureMethods`. It is included into the model class immediately after
the `generated_attributes_methods` module defined in ActiveModel, so association methods
override attribute methods of the same name. *Josh Susser*
The point of this change is to allow more flexibility in working with associations in your model classes. When you define an association, ActiveRecord automagically generates some methods for you to work with the association. For example, a
has_many :patches association generates the methods
patches= (and a few others).
Previously, those association methods were inserted directly into your model class. This change moves those methods into their own module which is then included in your model class. Your model gets the same methods through inheritance, but also gets to override those methods and still call them using
super. Let’s take a look at two ways this makes things easier for you.
Sometimes you want to replace the standard generated association methods. That’s always been easy to do simply by defining new methods in your model class. The only wrinkle was that you had to make sure you defined your method after you set up the association, or calling
has_many would overwrite your method, since last writer wins. That was usually not a problem, but sometimes plugins or other monkey patching extensions could add an association after your model’s class was defined, which wouldn’t give you a chance to add your method afterwards. With this change, you don’t have to worry about those order dependencies anymore. Since those methods are generated in their own module, the order doesn’t matter. This is a pretty small issue all told and I doubt it affected many people, but it’s still worth mentioning.
The real reason for this change is being able to compose your own methods with the standard generated methods. Before this change, you’d have to use
alias_method_chain or some other fancy footwork to layer your own logic on top of the standard association functionality. Either that or you’d have to somehow duplicate the standard behavior in your own method. Ick. Now you can compose methods using inheritance and
super, the way Alan Kay intended you to. Here’s the example from the docs:
class Car < ActiveRecord::Base
self.old_owner = self.owner
If you’re familiar with ActiveRecord it’s probably fairly obvious what’s going on there, but I’ll spell it out for the new kids. When you define the
belongs_to :owner association, that generates a standard
owner= method, and puts it in the module named
Car::GeneratedFeatureMethods, which is the closest ancestor of class
Car. If you’re curious what this looks like, fire up the rails console and type
Car.ancestors to see the class’s inheritance chain. (Or use your own app and model, since that will be much easier than making up a new app just to see that one thing.)
In this Car class, you can see that changing owners keeps track of the old owner, so the new owner knows who to call when he can’t figure out how to open the trunk. The generated
owner= method does a fair amount of stuff including managing counter caches, running callbacks, setting inverse associations, etc. Skipping that could break a number of things, so after saving the old owner, you also want to run the generated method. Since it’s in a module that Car inherits from, you only have to call
super to get that to run. No muss, no fuss!
One more step towards simpler OOP in Rails! Thanks to my fellow Ruby Rogues Avdi Grimm and James Edward Gray II for complaining about the old state of things enough to motivate me to finally go fix this.