On May 14, 2009, at 8:02 AM, Russel Winder wrote:
On Wed, 2009-05-13 at 15:36 +0200, Hans Dockter wrote:
[ . . . ]
I have to admit to being ambivalent on the new task definition
notation.
On the one hand I prefer it to what was before, on the other hand it
is
not a Groovy script per se and so is difficult to read.
If this were just a DSL then clearly AST transforms are a great tool
for
handling "parsing on the fly" -- it ensures a language that might
otherwise have to have been an external DSL can be an internal DSL.
However great play is made of Gradle specifications being Groovy
scripts, not scripts in a DSL. This means a Gradle script should
clearly and obviously be a Groovy program and this means AST
transforms
that change standard Groovy rules should not be used. In this case a
task specification is not obviously Groovy.
Gradle scripts have never been stand alone groovy code (as you of
course know). We don't claim them to be nor would it give any
advantage to our users. For 0.7 we plan to merge the functionality of
settings.gradle into build.gradle and we will use AST transformations
for this. But there is a fine line we don't want to cross. For me one
major problem with external DSL is that they are mostly declarative
and that it is impossible or very hard to use them as a toolset. With
AST transforms you can create a similar effect. This won't happen to
the Gradle DSL. All the Gradle elements will play nice with generic
Groovy logic and statements. Either by using them as they are or by
providing similar notations for use in statements. We don't want to go
wild with AST transforms. The less the better. But they have a place
in our DSL.
<snip>
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
