Do you know Ruby’s ‘Chainsaw’ method? | Hacker News Reader

Do you know Ruby’s ‘Chainsaw’ method?

rubylearning.com

46 pointsIndianGuru48 comments

I prefer to use define_method over method_missing when "metaprogramming". It allows you to explicitly define your "metamethods" up-front.

Using his example of the DoNotDisturb wrapper around InformationDesk, you could easily do something like:

  [:emergency, :flights, :local_transports, :hotels].each do |name|
    define_method(name) do
      check_lunch_break unless name == :emergency
      @desk.send(name)
    end
  end

Now you don't get the side effect of screwing up your exception handling and having to walk on eggshells with the rest of your coding in that class.

The other thing I like about this method is that it gets evaluated once, and then those methods exist. With method_missing, every single time you call one of those methods, it has to go all the way up the chain to find that method until it finally hits method_missing.

EDIT: Oh, and if nothing else, you can at least put the define_method inside the method_missing (I had a project that required method_missing once, so this is what I did). That way, it only has to crawl all the way up the inheritance chain once, then that method gets defined on your class, so subsequent calls to that method don't have to go all the way up the chain again.

Might not be much performance gain in Ruby, but when programming a rails app (where you're likely working on a class that inherits from ActiveRecord and 10 other classes), it helps.

Your approach of defining, even within method_missing is better. Defined methods instead of method_missing is also how Rails 3 got some of it's major speed boosts.

Oh, and another option would be to pull the common methods out into a module that you can include in each class with one line. I like this option, because then it’s trivial to go create another class called OutForVacation, in which you could include this module, and now you have another wrapper with all the same functionality.

That makes a ton of sense. It would also aid significantly in debugging, as you can see every method you created, rather than only being able to infer what they might be.

While I know this is a rubyist thread, I want to chime in as a Javascript developer. You can almost do the same thing there - joy! Probably not the best way to do it, but it's 3AM and I'm writing off the top of my head. And it's a little bit messy. And it gets rid of that pesky emergency case.

Within the object constructor:

  // assuming the desk object was inherited and accessible. There are several ways to do this.
  var thisContext = this; // unless you want to do some weird stuff with calling a function that returns a function that calls a function
  ["flights", "local_transports", "hotels"].forEach(function(fn) {
    thisContext[fn] = function() {
      check_lunch_break && desk[fn](arguments);
    };
  });

Granted, this doesn't get your methods on the prototype, and will incur a cost every time you create one of these objects. If you properly inherited from the desk class, it will overwrite them. And the emergency function will work just fine, if defined on desk.

Nitpickery indeed, but that won't work as expected. `fn` can be reused within the loop, depending on the runtime, so all methods will end up calling the same `desk[fn]`.

I think you might have misread the code.

Each `fn` is bound exactly once, `forEach` is not a loop.

Touché

You're right in that it won't work as expected - unless the desk methods are static. In reality, you would probably want to call

  desk[fn].call(thisContext, arguments);

How come no one has mentioned Forwardable and delegators ?

There's actually a fairly safe way to use method_missing. Just remember to call super if none of your conditions are met, that way you'll still get errors when commands are misspelled. You really shouldn't ever use method_missing without that.

He probably also should be checking if @desk actually has a method with the provided name (with @desk.respond_to?(method_name)) before attempting to call it.

When using method_missing in a proxy why bother checking? Just call the method and let wrapped object handle the errors. The stack trace will show you where to look for the error. The only reason I can see to check before calling is if you have different failure mode than the wrapped object. Otherwise you are duplicating logic.

It's a small thing, I admit, but I like getting a slightly cleaner stack trace since the exception happens in the wrapper module (where the error is) instead of getting all the way to @desk.

After I've spent the last 2~3 years reading funky rails stacktraces something like that doesn't bother me a bit. (I get more worried about older versions of jruby deciding to puke on internal ruby<->java mismatches at work) :)

He should also define respond_to? on the DoNotDisturb class. Relying on method_missing to pass calls to respond_to? to the proxied class will not work, as it is defined in Object. Responding to a method when respond_to? returns false breaks the class contract.

From the OP: I agree with you guys (or gals) on both calling super and redefining respond_to?(). Those are two of the "caveats" I mentioned at the end of the original post. I considered mentioning them explicitly, but the post is long enough already.

method_missing / AUTOLOAD is a great way to break any tools that rely on being able to introspect your classes.

For something as simple as this, just add the methods to the class in a loop. Then you class works just like every other class; no introspection is broken. It's also faster at runtime.

I can see how method_missing can break introspection, but I don't see how the same is true for Autoload. Could you give an example?

I believe jrockway is referring to AUTOLOAD in Perl (ie. its equivalent of Ruby's method_missing).

ref: http://perldoc.perl.org/perlsub.html#Autoloading

When I work with Java or C#, I accept this kind of code duplication as a fact of life.

Java has had dynamic proxies since 1.4. As long as you're working with interfaces, you can do the exact same thing as the example given in this post.

And the new dynamic support in C# gives it a direct equivalent to method_missing.

From the OP: I used dynamic proxies in both Java and C#. For example, I wrote the annotations introspector for Hibernate Annotations, and a memcached wrapper for a C# project. Both are proxy-based.

However, using dynamic proxies in Java feels like going against the grain of the language: strong typing and dynamic calls don't really like each other. As a result, you usually resort to Java/C# dynamic proxies only when you have no other option. I've yet to see anyone using a dynamic proxy just to remove duplication in a Java class.

C# dynamics might make dynamic proxies less clumsy in that language. Will try. Do you have experience with them already?

I haven't seen them used much in any of the open source Java projects I'm familiar with, I agree. We used them fairly extensively at my previous job, though, for implementing a mix-in pattern for boilerplate-free service endpoints, and they worked nicely. Outside of that, I use them al the time during development to add quick-and-dirty method call tracing when I'm trying to debug something.

I personally think that they're very much underused, and having based an interview question on them for a while, not well-known at all.

For me method_missing looks more like an anti-pattern because it's easy to miss, it's hard to debug, it's impossible to scan visually, it messes up code lookup if you use IDE, it messes up search if you don't.

A better analogy to magic methods would be dynamite. There are a few situations where you should use it, but not many, and generally it's when there's no other option.

His example violates the principle that objects should represent things. (What is a DoNotDisturb?) Back to OOP school, metaprogrammer!

From the OP: I considered changing the names because I had the same concern, but in the end I figured that the current name was good enough for a toy example. In hindsight, you're probably right I should have used other names (although your sneering tone is not really necessary).

I'm going through the author's book right now (Metaprogramming Ruby). It's great.

FP fanboys will laugh so hard at this. The proper way to deal with duplication, as described in this article, is of course to use functors. With a general method_missing(), your compiler will not even catch spelling errors anymore.

> With a general method_missing(), your compiler will not even catch spelling errors anymore.

Ruby isn't compiled. Whether or not it catches typos is up to your logic. All of my method_missing calls eventually hand off to the parent class's implementation when they can't match anything.

> The proper way to deal with duplication, as described in this article, is of course to use functors.

Except this is ruby. Ruby has modules to deal with duplication between classes and code blocks (closures, which can be bound to variables) for general use. It also allows for a rather clean implementation of the proxy design pattern via method_missing. Anything dealing with classes assumes OOP, not FP.

I only have begun to figure out that I don't know anything about FP but your comment seems rather absurd in this context.

"I use method_missing()to remove duplication ... On the other hand, I usually think twice about using method_missing() for cosmetic reasons, like getting cool method names such as find_by_name_and_address()."

That seems backwards to me. I use magic methods to define methods that can only be defined at run time, like his example of creating methods based on schema introspection.

Using magic methods breaks a lot of tools: IDE code completion, reflection, documentation generation so I always explicitly define methods unless it's not possible.

I've found that the only good time to use method_missing is when I'm wrapping an object and need to send all but a couple methods through to it untouched. I've really never used it for anything else.

I don't do any Ruby, but: can someone give a non-contrived situation where you would want to do this? What problem does this solve?

The most sited example is ActiveRecord where finders can be auto-generated. For example `find_by_name_and_address` will be defined on the fly the first time it is used in code. Another common usage is a wrapper class that provides a unified interface to a set of underlying objects. If many of these objects have almost the same interface `def method_missing(method,args); @object.send(method, args);end` can save a lot of redundant definitions.

Good example would be XML/HTML builder. For eg in Ruby http://builder.rubyforge.org/

  require 'rubygems'
  require_gem 'builder'

  builder = Builder::XmlMarkup.new(:target=>STDOUT, :indent=>2)
  builder.person { |b| b.name("Jim"); b.phone("555-1234") }
  
  # Prints:
  # <person>
  #   <name>Jim</name>
  #   <phone>555-1234</phone>
  # </person>

Also see this recent HN thread: http://news.ycombinator.com/item?id=1626018

And why would you do this instead of just defining a print method that takes the XML tag and content as separate parameters?

Because the way above is more natural.

Not to me; I find it too cute. The reason I call it such is that it uses a powerful mechanism to implement a trivial thing.

I find using this mechanism in builders like this is more appropriate and not an abuse. Its definitely aids development & maintenance.

Conversely though I find that using it in ActiveRecord is cute (ie. a bad thing!).

Why do you find it cute in ActiveRecord? (Recall that I don't develop with Ruby or Rails, so I'm genuinely curious.)

First off, I feel using mechanisms like method_missing should be used carefully. The Perl community abused things like AUTOLOAD & monkey-patching some years ago and learnt hard lessons and have now established good practises for their use. I feel Ruby/Rails world is going through the same growing pains but it does look like they are now maturing (eg. Rails 3).

Now IMHO I see a builder as a good case for a method_missing mechanism (I think there were a few others mentioned in thread/post). No magic, just a simple one-to-one relationship between code and what it does (result):

  b.name "Jim"    =>       <name>Jim</name>

However I feel something like find_by_name_and_address in ActiveRecord is cute (both in nice and ugly sense!). There is so much more going on underneath an ORM that I'd be wary of the extra layers of complexity upon what is already an (acceptable) impedance mismatch.

Bottom line, an ORM is important to me and I don't want any loose cogs lying around! I'd prefer to be explicit here:

  # using DBIx::Class
  my $p = $schema->resultset('Addresses')->find({ name => '...', address => '...' });

So while find_by_name_and_address is a pretty nice aesthetic its feels more plastic cosmetics compared the elegant cosmetics that Builder solutions provide.

Disclaimer: I haven't touched Rails for about 4 years now. I don't actually know for certain that something like find_by_name_and_address did or still uses method_missing. It could actually build methods like these straight from schema introspection. I would guess method_missing was used to avoid a performance hit on building all these at startup? If so then this could be a good argument for using method_missing here!

As of now, it uses method_missing to catch the first call to find_by_name_and_address, then defines the method inline, so future calls are handled by an actual method.

Purely for aesthetic reasons.

Instead of:

    builder.person do |b| 
        b.name("Jim")
        b.phone("555-1234")
    end

You could write it like this:

    builder.tag!('person') do |b|
        b.tag!('name', "Jim")
        b.tag!('phone', "555-1234")
    end

Not sure if Builder does this, but in theory you could even do:

    builder.person do |b| 
        b.name = "Jim"
        b.phone = "555-1234"
    end

Not sure myself but it can also be written like this:

    builder.person do |b| 
        b.name "Jim"
        b.phone "555-1234"
    end

Right, which is what I'm trying to understand: what does this allow you to do that is not just a cute way to call a method?

I think the ActiveRecord example below is the answer I'm looking for, since it creates a method at runtime based on information that did not exist until runtime. But I need to read up on it to understand it.

Personally I find aesthetics an important part of programming. If it looks good to me then it often means I'm doing something right!

So I don't view it has cute but more it being succinct.

I also find aesthetics important, but I don't find this more aesthetically pleasing; it pings the "something's wrong" feeling. Being succinct is a goal, but it's not the only goal.

Yes its subjective. There will always be a difference in view between what is cute and what is not cute (and also what I think is cute today may also not hold true tomorrow!).

Reply on news.ycombinator.com