I think it’s a little easier on the eye and it has the advantage of working properly with Java object that do things like having isX() for Boolean properties.

While that extra code is a bit much to explain in a presentation (you’d have to explain GroovyObject and the nature of Groovy properties)[...]

In general, the Ruby version is somewhat cleaner, as is often the case.

A few years ago I threw a hissy fit when the way in which method dispatch was unilaterally changed (from calling invokeMethod on a GroovyObject whose default implementation delegated the call to the MetaClass to calling invokeObject on the MetaClass first and then calling it on the GroovyObject if that failed). This broke a bunch of my code.

Guillaume, every the diplomat, brokered a compromise which allowed me to keep my existing code essentially unchanged by adding GroovyInterceptable. He then dried the hot angry tears from my cheeks.

I don’t know if it’s still true, but there used to be something wacky in the extreme in the implementation of method invocation because it involved throwing and catching an exception whose message included the result of calling toString() on each parameter. This bit me when I had a parameter whose toString() method had the side effect of fetching an RSS feed from the Net, parsing it and building an HTML document from the resulting data. It took a while to find out why the code ran so slowly:)