ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bruce Atherton <>
Subject Re: <available> / <condition> breaking immutability
Date Tue, 27 Nov 2001 21:04:42 GMT
At 06:26 AM 11/28/2001 +1100, Peter Donald wrote:
> > Either of these solutions will work, but only by adding unnecessary
> > complexity for the user.
>god no. Its simplifying for the user. Any programmer who reuses the same
>variable to mean completely different things ... and thinks it is the "right
>thing" .... they would be called a fool. Yet you seem to think it is ok for
>build engineers ...

I think no such thing.

The properties in <tstamp> always stand for the time that tstamp was 
called. How is that "different things"?

Even for the <available> task which I find a debatable one, consider this 
case. It is obviously artificial but makes a point:

     <available property="file.present" file="file.txt" filepath="mydir" />
     <!--  ... do stuff ... -->
     <delete dir="mydir" />
     <!--  ... do other stuff ... -->
     <cvs command="co" package="mydir" />
     <available property="file.present" file="file.txt" filepath="mydir" />
     <!--  ... WTF? ... -->

Of course there are ways around this, but a build engineer who wrote their 
system that way would not be "a fool". They would be expressing exactly how 
they want their build to work, until they hit up against Ant's rules and 
had to rework the problem into a more complicated form.

>Why? because we think it is easier for the user for things to behave

In general, I agree with you. Absent any other consideration, consistency 
is better than inconsistency. However, consistency should never be the 
single most important force. Consider the tradeoffs. In this case perhaps 
the benefits of consistency are such that it would be better to introduce 
this complexity, but it is not the slamdunk you seem to think it is.

>So far you are the only one claiming that having multiple sets of rules for
>property depending on the whims of a the particular task writer or due to
>historical factors is a good thing.

Historical factors should be a consideration since the change affects 
existing scripts, but again this is just one of the tradeoffs. That is not 
to say that they should be the most important force any more than 
consistency. But they should be considered.

A task writer's whim could only affect their own custom tasks. Your culture 
here would never let a whim make it into the repository. In which case, 
what do you care if they are sloppy programmers?

>The names of these tasks you just need to
>memorize and there is no where in recorded documentation that this behaviour
>should violate the bahevour of standard ant property rules.

Who ever said that? That would indeed be outlandish.

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

View raw message