« Return to Thread: Task DSL
Re: Task DSL
by Steve Appling
::
Rate this Message:
I'm still not sure that I understand the motivation to change from using
createTask to the keyword style syntax. I think this looks less like normal
groovy code (which makes it harder to initially understand). Perhaps I'm just
ranting about DSLs in general, which are always a balance between convenience
and ease of learning.
That said, if you are going to use a keyword style syntax, I would prefer a
keyword to create a new task that looked more like a verb - perhaps createTask
or newTask. I think the keyword task is confusingly close to the Project.task
methods and Project.getTasks. If I was going to the javadoc to try to
understand what methods in project were available to me, I would find this
confusing.
There is already a method to add actions to a task. Why is the "<<" syntax
needed? It just seems like more non-obvious magic. Could you not just use:
task hello.doLast { stuff to do }
I do like the idea of making more of a distinction between action closures and
configuration closures. The 0.5.2 syntax was confusing initially.
Hans Dockter wrote:
> We plan to make another change to the Task DSL before we release 0.6.
>
> At the moment the behavior that if you pass a closure to an existing
> task, the closure is used for configuring the task object. If you pass a
> closure to a task when creating a task, this closure is used as an
> action. The reason for this behavior is that we wanted to make Gradle
> behave as convenient as possible for the major use cases. If you create
> a simple task like HelloWorld, you usually don't want to configure it
> but want to add an action. And if you are accessing a task provided for
> example by the Java plugin, you usually want to configure it. The
> pay-off for this behavior, is that it can be a bit confusing at the
> beginning. And it is different from the normal Gradle behavior, which
> always uses closure assigned to objects for configuring them. The use
> case that made us change our mind about what is the best behavior, is
> when you don't create simple tasks but tasks of a custom type (e.g.
> Jar). In such a case you often want to configure the tasks when you
> create it (in contrast to simple tasks).
>
> We plan therefore to change the DSL in the following way:
>
> task hello << { <action> }
> task hello { <configure> }
> task myJar(type: Jar) { <configure> }
> existingTask << { <action>} // equivalent to existingTask.doLast
> existingTask { <configure> }
>
> We were also thinking about using the work 'do' instead of <<. That
> would be nice to read. But this is not trivial to implement in Groovy.
> And the << operator is already used in Groovy for adding elements to a
> list, which is something similar to adding an action to a task.
>
> Feedback is very welcome
>
> - Hans
>
> --
> Hans Dockter
> Gradle Project lead
> http://www.gradle.org
>
--
Steve Appling
Automated Logic Research Team
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
createTask to the keyword style syntax. I think this looks less like normal
groovy code (which makes it harder to initially understand). Perhaps I'm just
ranting about DSLs in general, which are always a balance between convenience
and ease of learning.
That said, if you are going to use a keyword style syntax, I would prefer a
keyword to create a new task that looked more like a verb - perhaps createTask
or newTask. I think the keyword task is confusingly close to the Project.task
methods and Project.getTasks. If I was going to the javadoc to try to
understand what methods in project were available to me, I would find this
confusing.
There is already a method to add actions to a task. Why is the "<<" syntax
needed? It just seems like more non-obvious magic. Could you not just use:
task hello.doLast { stuff to do }
I do like the idea of making more of a distinction between action closures and
configuration closures. The 0.5.2 syntax was confusing initially.
Hans Dockter wrote:
> We plan to make another change to the Task DSL before we release 0.6.
>
> At the moment the behavior that if you pass a closure to an existing
> task, the closure is used for configuring the task object. If you pass a
> closure to a task when creating a task, this closure is used as an
> action. The reason for this behavior is that we wanted to make Gradle
> behave as convenient as possible for the major use cases. If you create
> a simple task like HelloWorld, you usually don't want to configure it
> but want to add an action. And if you are accessing a task provided for
> example by the Java plugin, you usually want to configure it. The
> pay-off for this behavior, is that it can be a bit confusing at the
> beginning. And it is different from the normal Gradle behavior, which
> always uses closure assigned to objects for configuring them. The use
> case that made us change our mind about what is the best behavior, is
> when you don't create simple tasks but tasks of a custom type (e.g.
> Jar). In such a case you often want to configure the tasks when you
> create it (in contrast to simple tasks).
>
> We plan therefore to change the DSL in the following way:
>
> task hello << { <action> }
> task hello { <configure> }
> task myJar(type: Jar) { <configure> }
> existingTask << { <action>} // equivalent to existingTask.doLast
> existingTask { <configure> }
>
> We were also thinking about using the work 'do' instead of <<. That
> would be nice to read. But this is not trivial to implement in Groovy.
> And the << operator is already used in Groovy for adding elements to a
> list, which is something similar to adding an action to a task.
>
> Feedback is very welcome
>
> - Hans
>
> --
> Hans Dockter
> Gradle Project lead
> http://www.gradle.org
>
--
Steve Appling
Automated Logic Research Team
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
« Return to Thread: Task DSL
| Free embeddable forum powered by Nabble | Forum Help |
