On Wed, 2009-05-13 at 20:43 +0200, Hans Dockter wrote:
[ . . . ]
> You create as task with createTask("name"). But you can access the
> task with name (unquoted). You could also argue the latter is not
> normal groovy code (and may be you do). The alternative would be to
> say task("name") or with 0.6 tasks.getByName("name"). But I think it
> is nice to access a task like a variable. It is not just convenient
> for the writer, it is also nicer and better to read. One major
> motivation for Adam to change the 0.5.2 behavior was the mismatch
> between using strings for creating task vs. the unquoted name for
> accessing them (Adam, please correct me if I'm wrong). And I think the
> new syntax is therefore more consistent and nicer (better) to read. It
> is kind of funny. Some people (the developers in any case :)) really
> like it. And we were almost surprised that not everybody liked this
> change. But we had our reasons for this and it was not just DSL hype :)
The core problem here is the use of strings to represent symbols. (I am
assuming this is why Ruby has symbols separate from strings.)
Using strings as labels for things in a program means that typing (as in
on the keyboard) errors can lead to total confusion. Using some form of
symbol that the language parser processes means you get an easier
unification of all instances of the symbol, and hence easier error
detection.
I am all for using variables as much as possible as labels, I therefore
really don't like using a string in createTask -- this is why I used a
map for target definition in Gant, but even that is fraught with danger
since it is auto stringified and so actually you loose the error
detection.
So I like the basic idea of a task name being a symbol that the compiler
treats as a variable. I wonder though if it might be easier just to do:
name = newTask { . . . }
?
> We had a discussion a while back about the general approach for the DSL.
>
> See: http://markmail.org/message/uiejxtpqwbsa74sc
>
> Some experienced DSL writers recommended strongly to go for
> declarative vs. describing operations. And I agree with them. Again I
> think this is nicer and better to read.
Steve obviously read things differently, but I'm afraid I still stand by
my declaration not action position.
> The Project.task and getTasks method are replaced by the methods of
> the new tasks container (e.g. project.tasks.all/getByName/...). At
> least it is consistent to what we do in configurations/dependencies/
> repositories.
Consistency is always good in these things.
> > 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 }
>
> Now here I will use the normal groovy code argument :)
>
> List list = []
> list << 'String' // normal Groovy code
>
> I think to use doLast you would have to use parentheses:
> task(hello).doLast { ... }
>
> Another argument is: what are the major use cases? If I create a
> custom task, I just want to add an action and I don't care about
> doLast and doFirst. It is rather confusing in this context to use
> doLast and doFirst (and in fact doFirst and doLast has confused quite
> a few people at the beginning). Of course what we could do would be to
> provide an additional method do, which is equivalent to doLast. But
> then we would still have the parentheses problem.
Another analogy is with hooks in Emacs. The hook is a thing to which
actions can be appended, it is a list of actions. the "do first" and
"do last" are just lists of actions so an inserter semantics is exactly
what is happening, and so the traditional idiom of using << applies.
[ . . . ]
--
Russel.
============================================================
Dr Russel Winder Partner
Concertant LLP t: +44 20 7585 2200, +44 20 7193 9203
41 Buckmaster Road, f: +44 8700 516 084 voip:
sip:[email protected]
London SW11 1EN, UK. m: +44 7770 465 077 xmpp: [email protected]
signature.asc
Description: This is a digitally signed message part
