I still have one reservation about this new syntax.
On Fri, May 15, 2009 at 2:31 AM, Adam Murdoch <[email protected]> wrote: > > So, given this, we ended up with: > > task name(options-map) { configure-closure } where options-map and > configure-closure are optional. > > This addresses the above issues, at the cost of some not-so-common groovy > code. Personally, I think this is worth the trade-off. > > Note also that the above syntax transforms naturally into the syntax for, > say, configurations, so that we could allow in the future: > > tasks { name(options-map) { configure-closure } } > > or > > configuration name(options-map) { configure-closure } > I really like this part. I like the clean syntax, the configure-closure consistency with other stuff, and I really like the tasks {} syntax suggestion. All very nice. > > > > >> 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 } >> >> > You can do this, if you prefer. > > A few reasons for adding the << operator: > - We're just doing what groovy does in this instance. You're adding an > action to a task, so we use the same syntax that groovy uses for adding > things to a collection. In this sense, it's not really non-obvious at all if > you know groovy. It helps you understand by drawing your attention to the > analog with adding things to a collection. > - It's more concise, as this is a very common thing to do. > - doLast and doFirst don't really make sense when you declare a task. > Providing << avoids this to some degree. > > 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' } -- John Murph Automated Logic Research Team
