ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: <available> / <condition> breaking immutability
Date Mon, 26 Nov 2001 22:32:22 GMT
On Tue, 27 Nov 2001 07:29, Steve Loughran wrote:
> I dont know what the right action should be here. "Properties are
> immutable" is a simple concept, and easy to remember. "Properties are
> mostly immutable" is more complex, as "mostly" needs so much clarification.


> Right now we have:
>  some conditional tasks overwrite properties when true, but dont unset them
> when false
> And we should really have either
>  conditional tasks set and unset properties based on their true/false state
> or
>  conditional tasks can't overwrite existing properties; a warning is
> printed instead
> I think this one will have to be opened up for some consensual decision
> making.


> As to how to patch the code, all the tasks in question all use
> Project.setProperty(), probably assuming that this code would implement
> immutablity, whereas that is really implemented in Property.addProperty for
> all but user properties.


> It would make sense to refactor the immutability code into the Project
> class itself, so that all tasks which set a property could make use of it.
> Something like two methods, one for conditional setting and another for
> unconditional

works for me. (as long as backwards compatability is also kept for 
non-ant-dev maintained tasks).

> with the refactoring it becomes easier to change the behavior, and future
> tasks can use the same api calls to get the same functionality. This
> refactoring could also be done before any decision is made on how to treat
> the conditional assignments, as now there is just one place to change.

The problem is that some people actually rely on mutability and have written 
custom tasks to write immutable properties. I don't really mind not 
supporting them as we told them it was a bad idea, completely unsupported etc 

I think the question of whether we have a central policy regarding property 
(aswell as taskdef/datadef) immutability is interesting. If we do implement 
the central policy then no one can bypass it which is good because then we 
have less special cases to support. If we implement it on a per-task basis 
then we can have flexability - not that I am convinced we need it.



 We shall not cease from exploration, and the 
  end of all our exploring will be to arrive 
 where we started and know the place for the 
        first time -- T.S. Eliot

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message