Comments on: Groovy 1.6 and Per-Instance Metaclass

By: Tim Yates

Tim Yates — Thu, 26 Feb 2009 09:03:55 +0000

Ahhh cool! Thanks for the reply! It was the example that confused me

Keep up the Groovy posts, it’s sometimes hard to work out what’s new (and why it’s useful) from the release notes

Thanks again!

By: Guillaume Laforge

Guillaume Laforge — Thu, 26 Feb 2009 08:54:05 +0000

Just a small remark: per-instance MetaClass already existed and worked for POGOs. The “new feature” is that we can now also do the same with POJOs.

By: Ivan Moscoso

Ivan Moscoso — Thu, 26 Feb 2009 05:38:59 +0000

Hi Tim– not a stupid question at all! Effectively you get the same behavior between my example and yours in pure Groovy code. One difference I spot though is that, while the metaclass approach will still work as expected in a Java world, you can’t invoke a closure the same way as a method in Java.

If, say, you were working in a mixed environment, and a Java developer needed to reference your Groovy classes, they could still reference that ‘postProcess()’ as follows:

// Java code
new ReservationService().postProcess();

If using closures, this would *not* compile (the closure is not the same as a method). Instead, you would have to invoke the closure as follows:

import groovy.lang.Closure;
/* … */
// Java code
ReservationService r = new ReservationService();
Closure postProcessor = (Closure)r.getPostProcess();
postProcessor.call();

So the metaclass method can be changed from Groovy in the original example, and Java code can still reference it as a method. With closures, you need to be aware of the fact that you have exposed Closures if your code is running, say, within an existing Java framework.

This might not be a huge factor if you are only running in a Groovy environment such as Grails (I use closures a lot like that anyway), but the distinction still remains.

By: Tim Yates

Tim Yates — Wed, 25 Feb 2009 23:29:34 +0000

Sorry…that was your code… (badly formatted)…this is the closure code:

//
// Representation of an airline booking system
//
class ReservationService {
def name
def reserveSeat = { flightNumber ->
/* some network call.. */
return true
}

def postProcess = { }
}

class Reservation {
def bookFlight(flightNumber, service) {
def confirm = service.reserveSeat(flightNumber)
if (!confirm) {
service.postProcess = {
println “Error for provider ‘${service.name}’”
}
}
service.postProcess()
return confirm
}
}

reservation = new Reservation()

delta = new ReservationService(name: “Delta”)
united = new ReservationService(name: “United”)

assert true == reservation.bookFlight(“1234″, delta)
assert true == reservation.bookFlight(“1234″, united)

// Mock out our connection to Delta
delta.reserveSeat = { return false }

// The following prints an error, due to ‘postProcess’
assert false == reservation.bookFlight(“1234″, delta)

By: Tim Yates

Tim Yates — Wed, 25 Feb 2009 23:28:22 +0000

This is probably a stupid question, but how does this differ from using closures:

//
// Representation of an airline booking system
//
class ReservationService {
def name
def reserveSeat(flightNumber) {
/* some network call.. */
return true
}

def postProcess() { }
}

class Reservation {
def bookFlight(flightNumber, service) {
def confirm = service.reserveSeat(flightNumber)
if (!confirm) {
service.metaClass.postProcess = {
println “Error for provider ‘${service.name}’”
}
}
service.postProcess()
return confirm
}
}

reservation = new Reservation()

delta = new ReservationService(name: “Delta”)
united = new ReservationService(name: “United”)

assert true == reservation.bookFlight(“1234″, delta)
assert true == reservation.bookFlight(“1234″, united)

// Mock out our connection to Delta
delta.metaClass.reserveSeat = { return false }

// The following prints an error, due to ‘postProcess’
assert false == reservation.bookFlight(“1234″, delta)