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

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

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!).

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

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.