Hi Dierk,
thanks for your feedback.
On May 3, 2009, at 9:31 PM, Dierk König wrote:
interesting to see both words "ruby" and "grape" in one domain
name ;-)
I'd like to get some feedback on the new task definition DSL I've
added to trunk.
I do not feel very comfortable with it.
It is too far away from usual Groovy syntax for my taste.
How we could get any decent IDE support for this?
As far as I understood Ilya from JetBrains, the IntelliJ Groovy DSL
API would make it possible to support such a syntax.
atm I see lots of DSLs popping up everywhere.
Whenever it is possible to provide a fluent API, I prefer this over
inventing the next DSL (that has to be learned and remembered).
We have thought about this quite a bit. I'm not sure here. ATM we have
three approaches (often the user's have a choice):
- Fluent API
createTask('someTask').
setDescription('Some Desc).
setEnabled(true)
- Builder
createTask('someTask').configure {
description = 'some desc'
enabled = true
}
- Map
createTask('someTask', description: 'some desc', enabled: true)
I see the argument of the content assistant for the fluent API. But
for example if you work with dynamic properties, this is only of
limited use. In general I think the builder syntax provide better
readability and is more groovyish than the fluent API (e.g. you don't
need to use setter/getter). Anyway, in many cases we provide all of
them, as it is often a matter of taste and context. We have talked at
JAX about the planned feature in Groovy 1.7 for providing metadata
information for builders to improve IDE support for them. So it is
just a question of time when IDE support for builders will be as
convenient as for fluent API's.
So what about custom syntax elements? They can provide context and
improved readability. I think they are important. After all, it is a
DSL and not just an API. And we will get IDE support for this. Usually
those custom elements should integrate seamlessly into statements.
With the new task syntax this is not the case ATM. I will comment on
this in another email. One line we won't cross with Gradle is to use
AST transformations for providing very tailored DSL elements. For some
domains this can be a very nice approach (e.g. Spock). But for Gradle
it would defy the whole idea of providing a flexible toolset vs. a
purely declarative approach.
- Hans
cheers
Dierk
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
