Adam Keys is Thinking

BMW and Mercedes produce cars in direct competition. Further, everyone else in the auto industry likes to use them as benchmarks. Read a car magazine and count the superlatives like “more legroom than a Mercedes S500” or “more horsepower than a BMW 330i”. Its a market out there; everyone is incentivised to produce better stuff every time around.

However, you won’t ever find them boasting about top speed[1]. BMW or Mercedes don’t make cars that go faster than 155 MPH. Many moons ago, these car makers made a gentlemen’s agreement to limit their cars to a certain top speed. They probably did this for safety reasons - there just isn’t much need to go that fast and its probably inadvisable for most folks.

Why adhere to these agreements? At any point, BMW or Mercedes could break this agreement and achieve some kind of short-term numerical superiority. But this would end in an arms race that doesn’t really improve the every-day usage of their cars. So really, it’s in each company’s interest to maintain the agreement.

In the land of software development, we have gentlemen’s agreements as well. When I picked up Python in 1999, I learned that they didn’t have a distinction between public, protected and private object attributes. Many decried this, but the general idea was that we’re all adults and do the responsible thing.

Fast forward six years years. At first I was somewhat put off that Rails modifies the standard Ruby libraries. Many people are still put off about this. But I’m OK with it. If you have the chance to drive improvements in an ecosystem without waiting for the core maintainers to release a new version of Ruby, why not?

Many also decry the situation we find around Rails plugins. Its argued that one shouldn’t go around mucking about inside Rails to add functionality. And sure enough, plugins sometimes break when the core team changes Rails, even in the slightest of ways.

No surprise, I’m fine with this. Improving a system from the inside is too appealing to pass up so that I can claim some kind of virtuousness.

Should Rails have a defined internal interface or extension mechanism? Sure, sounds great! But we shouldn’t stop improving it outside the Rails core process just because sometimes we get burned.

The alternative is to define a known set of hooks by which we can modify behavior in a post-hoc fashion. Merb is taking this approach, and I’m eager to see how it works out. My take is that limiting people to extension along axes that the core developers imagined in a pre-hoc manner is too limiting. I hope I am proven wrong.

When it comes to Ruby or Rails, I think we already have a gentlemen’s agreement. We accept that extending systems using the facilities Ruby provides is useful, so we don’t complain too much when we get burned[2]. Accepting this is, in my experience, an empowering aspect of using Ruby that lets me worry about really interesting problems.

fn1. Except maybe for the M and AMG tuner variants of their mass-production cars

fn2. where “too much” is defined by the prudence of the extension mechanism used

…which is just a fancy way to say that this works like I think it should:

>> [['foo', 1], ['bar', 2], ['honk', 1000]].partition { |str, val| val > 999 }
=> [[["honk", 1000]], [["foo", 1], ["bar", 2]]]

Which beats the pants off this:

>> [['foo', 1], ['bar', 2], ['honk', 1000]].partition do |pair|
?>     str, val = pair
>>     val > 999
>>   end
=> [[["honk", 1000]], [["foo", 1], ["bar", 2]]]

So, you see, the array elements get unpacked into @str@ and @val@ inside your block. Which is unexpected, but totally and thoroughly lovely. To my eyes, the former is much easier to read.

“I need a new drug”:http://youtube.com/watch?v=MMSFX1Vb3xQ. One that won’t quit. One that will let me sensibly structure the use of blocks in Ruby such that they can run across multiple lines and yet still chain blocks together.

OK, so its not really a drug I need, per se. Though, I’m sure what Huey Lewis really needed was a new drug. But what I need is a convention, or perhaps some syntax. It should say to you, “HEY. Adam’s doing something clever with blocks here. Keep your eyes open.”

I find myself desiring a new syntax and/or convention, when using blocks. I’ve been trying to write in a more functional style lately, especially a pure-functional style wherein you never call a method for its side-effects. I don’t think I’m the only person doing this. Jim Weirich sort of alluded to it in a post about “when to use @do/end@ vs. braces”:http://onestepback.org/index.cgi/Tech/Ruby/BraceVsDoEnd.rdoc. Rick DeNatale “took it a step further”:http://talklikeaduck.denhaven2.com/articles/2007/10/02/ruby-blocks-do-or-brace. I want to lay it bare.

Let’s start with something innocuous:

ary = [1,2,3]

result = ary.map do |n|
  x = n * 4
end

result # => [4, 8, 12]

You get the value back of each object in the array, mapped to the result of calling the block. Fun times. Now, let’s put it on one line and do something clever with it.

ary.map { |n| n * 4 }.select { |n| n == 4 } # => [4]

Now we’re cooking! Ruby’s syntax allows us to chain methods and blocks. Which turns out nice in this case where I want to filter down the array of mapped values. But let’s pretend we need to do something clever in those blocks.

  
    ary.map { |n|
      n * 4
      # Some
      # clever
      # things...
    }.select { |n|
      n == 4
      # More
      # clever
      # things...
    }.any? { |n|
      n == 4
      # Gratuitiou
      # clever
      # things...
    } # true
  

That’s the best I could come up with for chained, multi-line blocks. It looks “Weirichian”. Despite that, it kinda makes me vomit in my mouth.

So, since “I got awesome feedback on my last question of taste”:http://therealadam.com/archive/2008/04/28/can-i-send-you-a-message/, I’m tapping you, my favorite Ruby developer, for more. The ground rules are that you can’t extract the logic into a real method and you can’t jam everything onto one line. You have to use multi-line blocks. What looks good to you here?

@Object#send@ - the joy of Rubyists and the scourge of those who would write refactoring tools. Let’s talk about it.

I recently ended up writing some code that would have proven really hideous if I couldn’t call @#send@. So I had a class like the following (written using code generation for brevity):

class Foo
  %w{one two three}.each do |name|
    class_eval <<-EOC
      def #{name}
        '#{name}'
      end
    EOC
  end
end

I needed to call @one@, @two@ or @three@ from a bit of code that takes some user input (in this case, an attribute value in a template language). So I cooked something like this up:

%w{one two three foo}.each do |arg|
  meth = case arg
  when 'one'
    :one
  when 'two'
    :two
  when 'three'
    :three
  else
    raise 'Unknown arg'
  end

  puts Foo.new.send(meth)

end

So I’m using a case statement to convert valid method names to symbols, which I then pass to @#send@ and bam!, my method is called. This made my code a ton easier to write and I’m here espousing the technique to you.

But what is the drawback? Well, if someone were to ever really get up the courage to tackle the task of building a refactoring browser for Ruby, this sort of thing would give them fits. They can’t really tell where those methods are called on my class until they are actually called. Heck, given the code above, they can’t even figure out what methods exist on @Foo@ without running the code.

The other drawback is that this code is a little hard to read. Most new casual Rubyists won’t think to search for the symbol version of a method name. Its even harder if you’re still somewhat new to Ruby and you aren’t aware this sort of thing even happens.

For me personally, the concise code I can write with @#send@ far outweighs the drawbacks. I preach the importance of code reading regularly, and its how one can get over the “hump” that is knowing how to navigate software that sends dynamic messages to objects.

Your homework is to share how you feel about @#send@ in the comments.