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 05:00:21 GMT
At 09:49 PM 11/26/01 -0500, you wrote:
>Agreed.... thats why I'm bringing this up.
>But if we let <tstamp> change properties, then why not <available> and
>If we let everything change properties then we might as all be writing our
>build scripts in Perl!  :)

Don't get me wrong, I can understand and appreciate why you'd want 
properties to be immutable despite the counterintuitive behavior it 
produces for users to deal with, such as setting local properties before 
global ones. That's just an education problem.

I can also understand why there is debate around <available> and 
<condition>. In some sense, if the property is set before the task is run 
then the configuration of the build is incorrect in some way, since that 
should never be necessary save as a hack to get around immutable 
properties. It comes down to whether you want to make life easy on the user 
with an incorrectly set up build, or enforce the rigors of your paradigm. I 
tend to favour ease of use, but I'm funny that way.

But with <tstamp> and its properties, you have something very different. 
These properties are not set by the user but are constants within the 
program. <tstamp> is really a way of declaring "Give me the time now", and 
it just so happens that the way that time is communicated is through 3 
standard properties controlled completely by the task.

In a way, this becomes very similar to what WebDAV calls "Live Properties" 
and "Dead Properties". The live ones are generated by the server, the dead 
ones are under the user's control.

Hmm. Just thinking out loud, but suppose that Ant adopted something 
similar. There are user controlled properties, called Dead properties, and 
Ant system properties which are Live. The system will never affect Dead 
properties, the user cannot affect Live ones. The only thing the user can 
do to a Dead property is give it an initial value. The system can choose to 
do anything that is appropriate with Live properties, and it registers its 
built-in properties as Live before it parses anything from the user.

That provides some of the separation between properties you seem to have 
been looking for and clarifies why some of them might change in some 
circumstance. Any task can choose whether to allow changing a Live 
property, but it guarantees that a property specifically set by the user 
will not be changed in any way.

That begs the question of whether a property specified in an attribute to a 
task is a Live or a Dead property (other than the <property> task which 
produces Dead properties by definition). But by giving you a clear stopping 
point on the slippery slope you are worrying about, you should be able to 
decide that question based on what feels like the right answer rather than 
worrying about how you can explain the difference to users.

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

View raw message