Wednesday, July 18, 2007

Groovy and JRuby Cooperating?

Can it be true? Of course it can!

Graeme Rocher blogs about a new feature in upcoming Groovy 1.1 beta 3: support for Ruby-style "method missing" hooks!

In heavily metaprogrammed applications, it's very common to define methods on the fly in response to calls made. For example, in Rails ActiveRecord, no "find by" methods are defined out of the box, but you may still call "find_by_x_and_y_and_z" to run your specific query. In order to reduce the overhead of handling these "missing methods" (usually through parsing the called name), it's typical to generate new methods on demand, binding them to the called class. So if you call find_by_name and it doesn't exist, two things happen: the query is generated and run and a new find_by_name method is dynamically created for future queries.

After Graeme blogged about the typical way to dynamically create methods in Groovy, I tapped him on IM and we started to talk about how Ruby handles the same use case. We agreed that the overhead of overriding invokeMethod (Groovy's entry point for all dynamic calls) was problematic...it's already got enough to do without adding the method-generation logic. As it turns out, "method missing" was a perfect remedy, and pretty easy to add into Groovy. Graeme's already started work to modify Grails to take advantage of methodMissing and I'm sure it will catch on like wildfire in the rest of Groovydom. And as a result you, the JVM dynamic language community, gain the benefit of a little Groovy/JRuby cross-pollination.

So for all you haters out there who just love to pit language teams against one another I say this:

Nyah.

6 comments:

  1. Of course Ruby's method_missing was inspired by Perl's AUTOLOAD. That feature has been available since perl 5.0 - stable released in 1994.

    Nyah ;)

    ReplyDelete
  2. I thought Ruby's method_missing was inspired more by Smalltalk's MessageNotUnderstood, but my nyah was more for people who love to see language implementers fighting, rather than cooperating.

    ReplyDelete
  3. Nice post Charles. Thanks again for the idea :-)

    ReplyDelete
  4. Nice one - it's great to see ideas from one community benefiting another, that's the way it should be (even though it isn't always the way it is).

    ReplyDelete
  5. These are great news Charles, keep those cross-pollination ideas flowing both ways!

    ReplyDelete
  6. Yes I know - I was being facetious :>

    I am a big fan of interaction and cross pollination, so I probably should have been more explicit about my humour - but where's the fun in that?

    Great news on the 1.0 performance btw.

    ReplyDelete