On 6/04/10 12:01 AM, Spencer Allain wrote:
task abc << { action }
really is just shorthand for:
task abc { doLast { action } }
I actually need doFirst and doLast (and yes, it works with or without
the parens, so doLast or doLast() is preference at this point), so I
must vote to retain the ability to prepend and append at the execution
phase.
What sorts of things do you use doFirst/doLast for that you wouldn't use
tasks for?
I believe that most of the confusion occurs because the "default"
desired behavior is to have tasks that do something at execution time,
I wonder if this is will always be the case. As I mentioned in another
email in this thread, as we add more plugins, domain objects, and task
implementations, the need for task definitions with a task action should
reduce. Instead, you would use typed tasks, or configure existing tasks.
Even now, you can have completely functional builds without defining any
tasks in your build file. I imagine this set of builds will grow over time.
but the non-short form happens at configuration time only.
It probably would be quite disruptive to the parsing I suspect (and
existing scripts), but maybe the default behavior should be an
implicit doLast, and to have things that absolutely need to happen at
configuration time can use the configure closure.
Then the short form would simply be the "normal" form, and the "<<" is
much less relevant, as it's usually only more advanced operations that
might require much at configuration time:
task myTask { implicitDoLastRunAtExecTime }
task myTask { configure { runAtConfigTime } ;
implicitDoLastRunAtExecTime }
This is very similar to an earlier version of the task DSL. However, I
prefer the new behaviour, where the closure provided to the task
definition configures the task:
* I think we want to prefer typed task definitions (ie declarative
definition) over imperative style task definitions, because of the
benefits we get from declarative tasks definitions.
* Over time, I think most task definitions will use a task type, or will
configure existing tasks.
* It's consistent with the definitions of other types of domain objects,
where a configure closure is provided to the definition.
Having said that, there'll always be a place for ad hoc imperative
tasks, so it's important that we get them right too. Perhaps a better
approach would be to come up with a new task definition DSL that makes
it equally easy to provide both the configuration and execution time
code. I'm not sure what that would look like.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
