Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 77657 invoked from network); 26 Nov 2001 20:29:53 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 26 Nov 2001 20:29:53 -0000 Received: (qmail 4246 invoked by uid 97); 26 Nov 2001 20:29:52 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 4214 invoked by uid 97); 26 Nov 2001 20:29:51 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 4117 invoked from network); 26 Nov 2001 20:29:50 -0000 Message-ID: <01d701c176b9$18631ae0$0201a8c0@nordwand> From: "Steve Loughran" To: "Ant Developers List" References: <00d801c175ba$0d82b040$6401a8c0@darden.virginia.edu> <013e01c176a1$5cbb3730$c7688f80@darden.virginia.edu> Subject: Re: / breaking immutability Date: Mon, 26 Nov 2001 12:29:48 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N ----- Original Message ----- From: "Erik Hatcher" To: "Ant Developers List" Sent: Monday, November 26, 2001 9:39 AM Subject: Re: / breaking immutability > So, just to get clarification - > > You are ok with (and other such tasks that currently overwrite > properties) unsetting properties if the condition fails? > > That is my preference simply because it makes sense. If overriding a > property is necessary, the -D switch will do it so only builds that were > relying on strange effects would be breaking, I think. Or ones that relied > on the existence of a property even after a failed . > > 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 dont know what the right action should be here. "Properties are immutable" is a simple concept, and easy to remember. "Properties are mostly immutable" is more complex, as "mostly" needs so much clarification. Right now we have: some conditional tasks overwrite properties when true, but dont unset them when false And we should really have either conditional tasks set and unset properties based on their true/false state or conditional tasks can't overwrite existing properties; a warning is printed instead I think this one will have to be opened up for some consensual decision making. As to how to patch the code, all the tasks in question all use Project.setProperty(), probably assuming that this code would implement immutablity, whereas that is really implemented in Property.addProperty for all but user properties. It would make sense to refactor the immutability code into the Project class itself, so that all tasks which set a property could make use of it. Something like two methods, one for conditional setting and another for unconditional /** * set a property if the set flag is true, unset it if false * if the property is already defined warn/overwrite */ Project.setConditionalProperty(string name, string value, boolean set) /** * set a property, apply current mutability policy */ Project.setUnconditionalProperty(string name, string value) with the refactoring it becomes easier to change the behavior, and future tasks can use the same api calls to get the same functionality. This refactoring could also be done before any decision is made on how to treat the conditional assignments, as now there is just one place to change. -Steve -- To unsubscribe, e-mail: For additional commands, e-mail: