John Murph wrote:
I still have one reservation about this new syntax.
On Fri, May 15, 2009 at 2:31 AM, Adam Murdoch <[email protected]
<mailto:[email protected]>> wrote:
<clip ...>
For me, this is the big problem with the new syntax. The << operator
have such a HUGE importance to meaning, and yet being very non-obtrusive
syntactically causes me concern. Especially if one uses different
coding styles. For instance:
task doSomething {
configurationIt
config SomeMore
}
task notAgain << {
println 'You are not supposed to call me'
}
Especially when you have tasks that are many lines long this is O.K.,
but not great. However, we have a coding standard that puts the { on a
new line, such that it becomes
task doSomething
{
configurationIt
config SomeMore
}
task notAgain <<
{
println 'You are not supposed to call me'
}
The trailing << on the second task line just seems too easy to overlook,
and yet is quite meaningful to the behavior of the script. This is why
I would like (at least an option) for
task notAgain.do
{
println 'You are not supposed to call me'
}
While I agree that they are confusingly similar, I'm not sure that the .do is
any more obvious than the trailing <<.
I'm not sure of a better solution here. I have noticed myself making mistakes
while converting our project over to use the new syntax. Perhaps I'm just slow,
but I have already mixed up task and configuration closures a few times myself.
Previously if you had to do configuration on a newly created task you had to
call configure explicitly like:
createTask('myTask', type:Copy).configure { config here }
Existing tasks could be configured directly, however:
myTask { config here }
I don't think this was previously intended to be a feature, but it did
distinguish the use of the closure.
--
Steve Appling
Automated Logic Research Team
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
