ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bevan Arps <bevan.a...@actfs.co.nz>
Subject Re: <available> / <condition> breaking immutability
Date Mon, 26 Nov 2001 19:45:02 GMT

>You are ok with <available> (and other such tasks that currently overwrite
>properties) unsetting properties if the condition fails?
>
>What backwards compatibility issues will we have?  Are the other committers
>on board with this change?  I don't want to go to the effort of patching
>these things if its not an acceptable change.  I'm not sure when/if I'll get
>around to patching it, but this seems like an important issue.

I've been following this thread with some interest.

As a user with some moderately complex Build files, I agree with Erik's 
above comments about "expected" behaviour.

However, I'd actually go one step further. To me, if the property is 
already set before <available> (and similar tasks) fire, you have a broken 
build and you should get some sort of fatal error.

The decision has been made that properties are immutable - I have no 
problem with this (at least they aren't called variables, like they are in 
XSLT!). So, they really should be immutable and *any* task that changes 
this should be considered broken.

Just my 2c,
Bevan.


--
"Programming is an Art Form that Fights Back"

Bevan Arps (<mailto:bevan.arps@actfs.co.nz>bevan.arps@actfs.co.nz)
Senior OO Analyst, ACT Financial Systems

This communication  is confidential  to ACT  Financial  Systems  (Asia 
Pacific)  and is intended for  use only by the  addressee.   The  views and 
opinions  expressed in  this email  are the senders  own and do not 
represent  the  views  and  opinions of  ACT  Financial  Systems  (Asia 
Pacific).


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message