ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Diane Holt <>
Subject Re: <available> / <condition> breaking immutability
Date Tue, 27 Nov 2001 21:48:40 GMT
Before this discussion gets too carried away, it might be good to keep one
thing in mind: Once a property is set, it's set (barring coding it out of
existence). You can't use <available> to un-set a property -- if you've
checked for something that does exist, then remove that thing and check
for it again, the property will still be set (even though the second run
of <available> doesn't find it), unless you're doing the second
<available> within an <ant>/<antcall> and you've turned off inheritAll
(but in which case, you don't need any "mutability" behaviour for
<available>). And since properties set via <available> are intended to be
used in conjunction with if/unless, which only checks for set/not-set, the
only "reason" for keeping the behaviour as it is would be to keep that
backdoor of changing the actual value of a property -- there really isn't
any "legitimate" way of using the current behaviour (that I can think of,
anyway). While it might be a lot easier to change the value of a property
by going through that backdoor than, say, using <script>, I don't think
there's any way to say it's a "clean" way of doing it, and (sadly, since I
kind of like little "insider" workarounds like that :) most likely needs
to go away.


--- Bruce Atherton <> wrote:
> 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
> >consistently.
> 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:
> <>


Do You Yahoo!?
Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.

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

View raw message