I think I should say an additional
word about the recursive closure. The following lines are giving a quick (and incomplete) overview of the variable resolving process in Groovy. You may not understand all, just keep in mind that it is like an extension to the java way.
Given an expression like "a = b" it is a basic rule to evaluate the right side before the left side. That means we get first the value for b and then assign it to a. In an expression like "int i = 1" we evaluate the 1 to 1 (of course) and assign it to i. But when is i defined? It is defined
after the right side is evaluated, because it is on the left side. If you think of Java, where you have an expression like "int i = i" and the later i is a field, then the newly declared i will be initialized with the value of the field i. Any subsequent calls to i in the same block of code will not access the field, but the new local variable i. So keeping that in mind and looking at a closure such as "def c = {c()}" makes it clear, that the c inside the closure is not the c outside.
If I write "c = {c()}" then there must have been either a variable/property c, a dynamic property or a reference to a binding. If not the assignment to c will fail. But this also means, that c is defined in the closure. Given that it works the c will be the closure. Then having a code like
explains itself. The c is known.
But there is more. You can influence the way the closure resolves the c by adding setting a delegate.
the delegate is used as last resort for the variable resolving process. When the closure asks the delegate, a map, for "c", it will answer with the value of d, which is the same as the closure itself. Builder do use this a lot.
I hope I made things not too unclear