On 17/04/2013, at 22:22, Adam Murdoch <[email protected]> wrote:
> > On 18/04/2013, at 12:09 AM, Luke Daley <[email protected]> wrote: > >> http://forums.gradle.org/gradle/topics/reading_project_properties_triggers_configuration_of_any_deferredconfigurable_extensions >> >> How do we want to deal with this? > > There are several options: > > 1. Asking for project.properties triggers the configuration of all deferred > objects (as it does now) and we add some stuff to make it easier to deal with > this fact. For example, we may allow the configuration of a deferred object > only when configuring some other deferred object (more or less what the > workaround does) plus some reasonable error reporting when you break this > rule. > > 2. Asking for project.properties does not trigger any configuration, but > asking for a value from the map does. We add the same kinds of things as > above. > > 3. Asking for project.properties returns a map with a placeholder object for > those deferred objects that have not been configured. > > 4. Asking for project.properties returns a map that does not include any > deferred objects that have not been configured. > > 5. Asking for project.properties does not trigger any configuration nor does > asking for a value from the map, but touching the object in some way > (accessing a property, calling a method) triggers the configuration. > > I want to avoid #5 if possible, as the other options offer a stronger > guarantee (if you've got the object, it's been configured) and I don't think > we need the flexibility of #5. The other options also offer some interesting > options wrt mutability, as the object you get post-configuration does not > necessarily need to be the same object that the configuration logic runs > against. > > Anyway, we can start with #1 and incrementally move to #2 and then #5 in a > relatively backwards-compatible way if we need to. Do you want an issue? And/or story(s) in the spec? > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > > Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: > http://www.gradlesummit.com >
