On 18/04/2013, at 7:49 AM, Luke Daley <luke.da...@gradle.biz> wrote:

> 
> 
> On 17/04/2013, at 22:22, Adam Murdoch <adam.murd...@gradleware.com> wrote:
> 
>> 
>> On 18/04/2013, at 12:09 AM, Luke Daley <luke.da...@gradleware.com> 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?

Both, I reckon.


--
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

Reply via email to