ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 10404] - The way in which property values are used can at times be very unintuitive
Date Wed, 10 Jul 2002 15:59:16 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10404>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10404

The way in which property values are used can at times be very unintuitive





------- Additional Comments From wtff@freenet.de  2002-07-10 15:59 -------
Thanks for your answer. I had already tried that before and tested it again but 
this doesn't seem to work.

If I initially set a property to a certain value, then the property will retain 
this value forever. The condition task or the waitfor task do not overwrite 
this initally given value, which I would say, is correct because of properties 
being immutable.

What I try to do is to have some property that is set to "true" if a network 
connection is up and to "false" otherwise.

---

Besides: I also do not yet understand why immutability is s.th. desireable. Is 
there any obvious reason for this, or could you point me towards some 
documentation that helps me understand?
In xslt, variables are immutable because of technical reasons. Is that the case 
with ant as well, or is it a deliberate choice of taste? I once read that when 
coding in a functional style, variables are initialised once and should then 
remain immutable to prevent "sideeffects". However I cannot imagine, what these 
sideeffects may be...

--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message