Victor works on the Angular team at Google. He is interested in functional programming, the Web platform, and client-side applications. Being a language nerd he spends a lot of my time playing with Smalltalk, JS, Dart, Scala, Haskell, Clojure, Ruby, and Ioke. Victor is a DZone MVB and is not an employee of DZone and has posted 47 posts at DZone. You can read more from them at their website. View Full User Profile

Groovy: Resolve Strategies

03.28.2011
| 7553 views |
  • submit to reddit

A few weeks ago I had to deal with an interesting bug in one of my DSLs. I had a simple builder overriding propertyMissing and saving all missed properties to map inside the builder:

class SampleBuilder {

private savedObjects = [:]

void propertyMissing(String name, value){
savedObjects[name] = value
}

void printSavedObjects(){
println 'Saved Objects:'
savedObjects.each {
println "${it.key} = ${it.value}"
}
}

static build(Closure c){
def builder = new SampleBuilder()
c.delegate = builder
c()
builder
}
}

I always used that builder inside another class:

class Application {
static void main(String[] args){
def res = SampleBuilder.build {
name1 = 'value1'
name2 = 'value2'
}
res.printSavedObjects()
}
}

The output of the this chunk of code is:

Saved Objects:
name1 = value1
name2 = value2

But what will happen if I use my SampleBuilder in a groovy script?

def res = SampleBuilder.build {
name1 = 'value1'
name2 = 'value2'
}
res.printSavedObjects()

No objects will be saved in that map:

Saved Objects:

It may look weird but if you think about it a bit more it kind of makes sense. To understand why does it happen we need to know how Groovy resolves all missing methods and properties.

Groovy tries to find it by looking in the delegate of the closure or the owner of the closure or using both. You can also specify to use none of them and use Closure’s meta class to resolve missing methods and properties.

These are descriptions of all strategies from http://groovy.codehaus.org/api/groovy/lang/Closure.html:

  • DELEGATE_FIRST. With this resolveStrategy set the closure will attempt to resolve property references to the delegate first.

  • DELEGATE_ONLY. With this resolveStrategy set the closure will attempt to resolve property references to the delegate first.

  • OWNER_FIRST.With this resolveStrategy set the closure will attempt to resolve property references to the owner first

  • OWNER_ONLY. With this resolveStrategy set the closure will resolve property references to the owner only and not call the delegate at all.

  • TO_SELF. With this resolveStrategy set the closure will resolve property references to itself and go through the usual MetaClass look-up process.

OWNER_FIRST is a default strategy used by Groovy.

Let’s look one more time at our SampleBuilder. Why does it behave differently inside a class and inside a groovy script? First of all, let’s look at the way it works inside a class. As the default strategy is OWNER_FIRST it tries to find a missed property in Application class. It can’t find it and that is why it uses delegate property to resolve it. But in a groovy script you can always define global properties using this syntax:

key = ‘value’

Because all our properties are resolved by owner our delegate won’t be invoked. To make it work we just need to change the resolve strategy of our closure to DELEGATE_FIRST:

def builder = new SampleBuilder()
c.delegate = builder
c.resolveStrategy = Closure.DELEGATE_FIRST
c()
builder

If you run that groovy script again you will see what you would have expected to see in the first place:

Saved Objects:
name1 = value1
name2 = value2

From http://victorsavkin.com/post/4135607663/groovy-resolve-strategies

Published at DZone with permission of Victor Savkin, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags: