Metaprogramming in Ruby: It’s All About the Self

November 15th, 2009

After writing my last post on Rails plugin idioms, I realized that Ruby metaprogramming, at its core, is actually quite simple.

It comes down to the fact that all Ruby code is executed code–there is no separate compile or runtime phase. In Ruby, every line of code is executed against a particularself. Consider the following five snippets:

class Person  def self.species    "Homo Sapien"  endend class Person  class << self    def species      "Homo Sapien"    end  endend class << Person  def species    "Homo Sapien"  endend Person.instance_eval do  def species    "Homo Sapien"  endend def Person.species  "Homo Sapien"end

All five of these snippets define a Person.species that returns Homo Sapien. Now consider another set of snippets:

class Person  def name    "Matz"  endend Person.class_eval do  def name    "Matz"  endend

These snippets all define a method called name on the Person class. SoPerson.new.name will return “Matz”. For those familiar with Ruby, this isn’t news. When learning about metaprogramming, each of these snippets is presented in isolation: another mechanism for getting methods where they “belong”. In fact, however, there is a single unified reason that all of these snippets work the way they do.

First, it is important to understand how Ruby’s metaclass works. When you first learn Ruby, you learn about the concept of the class, and that each object in Ruby has one:

class Personend Person.class #=> Class class Class  def loud_name    "#{name.upcase}!"  endend Person.loud_name #=> "PERSON!"

Person is an instance of Class, so any methods added toClass are available on Person as well. What they don’t tell you, however, is that each object in Ruby also has its ownmetaclass, a Class that can have methods, but is only attached to the object itself.

matz = Object.newdef matz.speak  "Place your burden to machine's shoulders"end

What’s going on here is that we’re adding the speak method to matz‘s metaclass, and the matz object inherits from itsmetaclass and then Object. The reason this is somewhat less clear than ideal is that the metaclass is invisible in Ruby:

matz = Object.newdef matz.speak  "Place your burden to machine's shoulders"end matz.class #=> Object

In fact, matz‘s “class” is its invisible metaclass. We can even get access to the metaclass:

metaclass = class << matz; self; endmetaclass.instance_methods.grep(/speak/) #=> ["speak"]

At this point in other articles on this topic, you’re probably struggling to keep all of the details in your head; it seems as though there are so many rules. And what’s thisclass << matz thing anyway?

It turns out that all of these weird rules collapse down into a single concept: control over theself in a given part of the code. Let’s go back and take a look at some of the snippets we looked at earlier:

class Person  def name    "Matz"  end   self.name #=> "Person"end

Here, we are adding the name method to the Person class. Once we sayclass Person, the self until the end of the block is thePerson class itself.

Person.class_eval do  def name    "Matz"  end   self.name #=> "Person"end

Here, we’re doing exactly the same thing: adding the name method to instances of the Person class. In this case,class_eval is setting the self to Person until the end of the block. This is all perfectly straight forward when dealing with classes, but it’s equally straight forward when dealing with metaclasses:

def Person.species  "Homo Sapien"end Person.name #=> "Person"

As in the matz example earlier, we are defining the species method onPerson‘s metaclass. We have not manipulated self, but you can see usingdef with an object attaches the method to the object’s metaclass.

class Person  def self.species    "Homo Sapien"  end   self.name #=> "Person"end

Here, we have opened the Person class, setting the self toPerson for the duration of the block, as in the example above. However, we are defining a method onPerson‘s metaclass here, since we’re defining the method on an object (self). Also, you can see thatself.name while inside the person class is identical to Person.name while outside it.

class << Person  def species    "Homo Sapien"  end   self.name #=> ""end

Ruby provides a syntax for accessing an object’s metaclass directly. By doing class << Person, we are setting self to Person‘s metaclass for the duration of the block. As a result, thespecies method is added to Person‘s metaclass, rather than the class itself.

class Person  class << self    def species      "Homo Sapien"    end     self.name #=> ""  endend

Here, we combine several of the techniques. First, we open Person, makingself equal to the Person class. Next, we do class << self, makingself equal to Person‘s metaclass. When we then define thespecies method, it is defined on Person‘s metaclass.

Person.instance_eval do  def species    "Homo Sapien"  end   self.name #=> "Person"end

The last case, instance_eval, actually does something interesting. It breaks apart theself into the self that is used to execute methods and theself that is used when new methods are defined. When instance_eval is used, new methods are defined on themetaclass, but the self is the object itself.

In some of these cases, the multiple ways to achieve the same thing arise naturally out of Ruby’s semantics. After this explanation, it should be clear thatdef Person.species, class << Person; def species, and class Person; class << self; def species aren’t three ways to achieve the same thingby design, but that they arise out of Ruby’s flexibility with regard to specifying whatself is at any given point in your program.

On the other hand, class_eval is slightly different. Because it take a block, rather than act as a keyword, it captures the local variables surrounding it. This can provide powerful DSL capabilities, in addition to controlling theself used in a code block. But other than that, they are exactly identical to the other constructs used here.

Finally, instance_eval breaks apart the self into two parts, while also giving you access to local variables defined outside of it.

In the following table, defines a new scope means that code inside the block doesnot have access to local variables outside of the block.

mechanismmethod resolutionmethod definitionnew scope?class PersonPersonsameyesclass << PersonPerson’s metaclasssameyesPerson.class_evalPersonsamenoPerson.instance_evalPersonPerson’s metaclassno

Also note that class_eval is only available to Modules (note that Class inherits from Module) and is an alias formodule_eval. Additionally, instance_exec, which was added to Ruby in 1.8.7, works exactly likeinstance_eval, except that it also allows you to send variables into the block.

UPDATE: Thank you to Yugui of the Ruby core team for correcting the original post, which ignored the fact that self is broken into two in the case ofinstance_eval.

This entry was postedon Sunday, November 15th, 2009 at 6:00 pm and is filed underRuby.You can follow any responses to this entry through the RSS 2.0 feed.You can skip to the end and leave a response. Pinging is currently not allowed.