I expect lazy initialization to run initialization right before it is needed. I prefer the "lazy" keyword because currently, in methods taking configuration blocks, Gradle runs the configuration eagerly. If in some places the same notation means eager and on others lazy, I would expect the inconsistency to be a source of bugs. Explicitly telling "lazy", would be clear for everyone, what will happen. The problem is that it always matters if a configuration is lazy or not, if some input argument is mutable (this can easily be done in Groovy by accident). It cannot be hidden from users of Gradle.
As for lazy task configuration: Allowing it, would be just very convenient for custom tasks. So to summarize, hiding laziness from users is just too late for Gradle 1.x. Of course, for Gradle 2 this could be changed. Until then, eager configuration can be made deprecated. So mostly, I'm ok with the changes but please don't hide important facts that a block is executed lazily or not. 2013/6/24 Luke Daley-2 [via Gradle] < ml-node+s1045684n5711406...@n5.nabble.com> > > On 23/06/2013, at 8:26 PM, kelemen <[hidden > email]<http://user/SendEmail.jtp?type=node&node=5711406&i=0>> > wrote: > > > Hi, > > > > As asked by Luke Daley, I'm sending my notes on lazy configuration to > the > > dev list. The idea of lazy task confiuration is roughly described here: > > > http://forums.gradle.org/gradle/topics/allow_tasks_to_be_configured_just_before_execution > > > > I will summarize: > > > > As I know, you are already working on lazy configuration. I would like > to > > have some notes and reguests. > > > > 1. I believe that my proposed lazy task configuration can solve many > > practical problems and is a simple concept: Easy to comprehend. In > short, > > lazy task configuration is a configuration block which is executed just > > before the task is executed. > > 2. I understand, that you want something more generic. If I can have a > word > > on it, I would like if you don't make something like > > publications { > > // lazy block > > } > > > > This is because making some of the configuration block lazy while others > > being eager (they must remain eager until Gradle 2 for backward > > compatibilty), is inconsistent and very confusing. So rather, I'd prefer > a > > syntax like this: > > > > publications lazy { > > // lazy block > > } > > > > This can be extended to other parts of Gradle in the future. > > > There's two main “issues” with this approach. > > 1. We are trying to avoid you have to tell Gradle when something should > happen; which leads into… > 2. To do this properly, Gradle really needs to know the nature of the > configuration so it can schedule it appropriately > > A strong goal is to make this work in such a way that a build script > author (different to a plugin author) isn't confronted with this issue and > it just works. > > -- > Luke Daley > Principal Engineer, Gradleware > http://gradleware.com > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://gradle.1045684.n5.nabble.com/Lazy-task-configuration-tp5711393p5711406.html > To unsubscribe from Lazy (task) configuration, click > here<http://gradle.1045684.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5711393&code=YXR0aWxhLmtlbGVtZW44NUBnbWFpbC5jb218NTcxMTM5M3wtMTMxMjM2NTcwMA==> > . > NAML<http://gradle.1045684.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > -- View this message in context: http://gradle.1045684.n5.nabble.com/Lazy-task-configuration-tp5711393p5711407.html Sent from the gradle-dev mailing list archive at Nabble.com.
