I hope that someone gets my
I hope that someone gets my
I hope that someone gets my
Message in a bottle

– The Police

Got a great question from Scott Porad the other day, asking about this line of code that’s produced by the scaffold generator in Rails 1.2 (note, in Scott’s application, his model is called content):

My question has to do with this line:

<td ><%= h content.send(column.name) %></ td>

What exactly is content.send(column.name) doing?

We all know that Ruby is an object-oriented language. However, many of us who are accustomed to .NET or Java may not realize that Ruby is really based on message passing, not method calling. The difference is so subtle that you can start using Ruby right away, and get pretty far, without ever knowing the difference. But this line in the scaffold code takes advantage of message passing to great effect.

When you write a Ruby class and define some methods inside of it, those methods are just predefined responses to certain messages.

    class Thermometer

        def temperature
            75
        end

    end

To think in terms of message passing instead of methods, try to read this code out loud as, “This is class Thermometer. It can respond to a message named ‘temperature’. It will respond with 75 when it receives the message.”

It looks like a method call in your previous favorite language, and the message-calling syntax in Ruby looks like the method-calling syntax in that old language, too:

    t = Thermometer.new
    puts "It is " + t.temperature " + degrees outside." 

When the Ruby interpreter sees t.temperature, it passes the message temperature to the t object. There are actually two ways we could have sent this message to the object. The first is what we did here. But there’s another, more generic way to send a message to an object, and that’s with the send method that’s available to every Ruby object:

    t = Thermometer.new
    puts "It is " + t.send('temperature') " degrees outside." 

Here we sent the message named ‘temperature’ to the object. Since Thermometer has defined a response to the temperature message, Ruby is able to locate that response and execute it.

This means that you can write code that does not know method names a priori. Let’s go back to the scaffold code. When you run script/generate scaffold Product, the generator has no idea what columns your Product table will have. Yet it is able to generate that code that will automatically display all of the data in your table. It’s able to do this by first reflecting on your table for the column names, and then asking your model for the value of the attribute with that same name:

    product.send(column.name)

So in this code, the product object is being passed a message, and it’s using the column name as the name of the message. ActiveRecord responds by returning the value of that column in the database. Beautiful!

In fact, your code can first find out if a given object will respond to a given message with respond_to?:

    t = Thermometer.new
    if t.respond_to? 'temperature'
      puts "Yes, it can tell you the temperature" 
    else
      puts "No, it can not tell you the temperature" 
     end

Today we looked at one way an object can respond to this message: providing a predefined response to a specific, named message. There’s another way to respond to messages, without writing def blocks at all.

But as Alton Brown likes to say, that’s another show.

Questions? Clear as mud? Drop me a comment.

---

Ready to learn more? Sign up now for Essential Rails