On Thu, 2010-04-08 at 06:34 +1000, Adam Murdoch wrote:
[ . . . ]
> The problem with the << form is that these 2 constructs:
>
> task mytask {
> .. do stuff at configuration time ..
> }
>
> task mytask << {
> .. do stuff at task execution time ..
> }
>
> are very similar in syntax but very different in semantics. The only
> syntactic difference is the '<<'.
>
> The '<<' form is only a shortcut for
>
> task mytask {
> doLast {
> .. do stuff at task execution time
> }
> }
Thanks for this bit. I have always been totally confused by the << and
non-<< forms. The above more or less clears my confusion.
> To me, the 9 or so characters we save with the '<<' form really aren't
> worth the confusion that the 2 forms cause. I'd rather we replaced it
> with something more explicit, like, for example:
>
> task mytask {
> execute {
> .. do stuff at task execution time
> }
> }
>
> This way, you only ever configure a task. It just so happens that for
> some tasks, you configure the action it will perform at execution time.
The trouble is execute seems like another hook giving the sequence
doFirst, execute, doLast whenever a task is executed. Is there a
reasons why the task initialization sequence isn't just the body and the
doFirst and doLast functional calls are just part of that sequence?
Make the pair of execution hooks explicit always:
task mytask {
. . .
doFirst { . . . }
. . .
doLast { . . . }
. . .
}
> I used to think that we should optimise the DSL for imperative task
> definitions like the above. Now I think that's the wrong way to go. As
> we add more typed tasks and more plugins, the need for imperative tasks
> lessens. And I think that we should optimise the DSL for declarative
> task definitions, such as you get with typed tasks or plugins, to
> encourage the use of declarative over imperative task definitions:
I still get confused by the type : key. Perhaps I have failed to read
the right bit of the documentation (very possible, cf. previous email on
handling changes in Gradle) but last time I looked there was no actual
explanation of the type : key it just sort of slipped in and got used.
Declarative over imperative is good, but don't become religious about
it. Having the balance of both is the right place to be since it allows
the shortest script to correctly describe the process that is a given
build.
> For example, this kind of task definition is declarative
>
> task copy(type: Copy) {
> from 'src/java'
> into 'build'
> }
>
> and is much preferable to this imperative task definition:
>
> task copy << {
> ant.copy(dir: 'src/java', todir: 'build')
> }
Actually I think both of these are declarative, it is simply that the
former represents an inheritance of a prototype task with amendment of
fields whereas the latter represents delegation with amendment of
fields.
Far more important that a spurious declarative/imperative tag is that
the former represents use of a Gradle built-in where the latter is
delegation to an Ant task.
> A big benefit of declarative task definitions is that Gradle can reason
> about them. For example, Gradle can automatically add task dependencies
> for the input files. It can apply up-to-date checking. It can validate
> the task's configuration. It can extract parallelism between tasks or
> even reason about how to distribute task execution across a bunch of
> machines. The same is true for plugins, user interfaces, and reports:
> They can all reason about declarative tasks. Whereas, imperative tasks
> are black boxes to them.
I'm afraid I have to repeat my point above, this is less a
declarative/imperative dimension, it is a built-in
inheritance/delegation dimension.
[ . . . ]
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:[email protected]
41 Buckmaster Road m: +44 7770 465 077 xmpp: [email protected]
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
signature.asc
Description: This is a digitally signed message part
