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 Tue, 27 Nov 2001 19:31:28 GMT
On Wed, 28 Nov 2001 05:55, Bruce Atherton wrote:
> At 08:05 PM 11/27/2001 +1100, Peter Donald wrote:
> >If I was the user and I had fubared my build setup then I would want to
> > know as early as possible.
> Sure, but how is your setup fubared here? 

they are generating a property somehow and then changing it. This will cause 
inconsistent behaviour of runtime depending on where it is used - whether the 
new value or the old value is used will depend on arbitrary factors of build 

> What is the downside for the user
> if they don't follow exactly the developers' vision of what a property
> should be?

err ... ant wont work properly?

> I would agree with you if the property-changing behaviour of <available>
> ran counter to most peoples' expectations of how it would work, 

It is. It violates the convention used in the rest of the tasks.

> Again, this is just my preference. I can see the arguments in favour of
> making the change.

yes ;)

> >Interesting idea ... needs exploration - I suspect it will be too complex.
> >However the real problem is that ant1 is not fully capable of dealing
> >with mutable properties and such a technique would need to wait till ant2.
> I'm not suggesting any change to code here. You already have a system that
> matches up to what I described, although it doesn't enforce the policies
> through code. I'm just talking about changing the design perspective on
> what a property is by expanding to two types. I'm trying to make it clear
> why it is still good design for your current system to have some properties
> that can be changed by certain select tasks.

Its an all or nothing thing for propertys in current scope. Either all tasks 
behave way X or all tasks behave way Y but we do not really want to have a 
bunch of inconsistent behaviour in a set of tasks that the user has no choice 
but to memorize.



"If you don't know where you want to go, we'll make 
sure you get taken." 
Microsoft ad slogan, translated into Japanese.

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

View raw message