Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 63646 invoked from network); 23 Mar 2002 23:57:56 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 23 Mar 2002 23:57:56 -0000 Received: (qmail 8557 invoked by uid 97); 23 Mar 2002 23:57:59 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 8541 invoked by uid 97); 23 Mar 2002 23:57:59 -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 8530 invoked from network); 23 Mar 2002 23:57:58 -0000 From: "Adam Murdoch" To: "Ant Developers List" Subject: RE: suggestion for if/unless syntax change Date: Sun, 24 Mar 2002 09:54:39 +1000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <004601c1d26a$3fbad620$0100a8c0@jose> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal 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: Jose Alberto Fernandez [mailto:j_a_fernandez@yahoo.com] > Sent: Saturday, 23 March 2002 10:52 PM > To: Ant Developers List > Subject: Re: suggestion for if/unless syntax change > > > From: "Adam Murdoch" > > > > > > From: Jose Alberto Fernandez [mailto:j_a_fernandez@yahoo.com] > > > > > > Humm. I think we are mixing two different things: (1) "if" > > > attribute of , , etc; > > > and (2) task. They are kind of different things, in my opinion. > > > > > > What I meant by coordinate, was that if the attribute now checks > > > for "false", then > > > and such should set things to "false" when the > > > condition is false. > > > They work the way they do in ANT1.x because the "if" attribute > > > works the way it does. > > > > > > > Ah, I understand now. Yes, probably should do > something when > > the condition is false. This would be different to the way > things work in > > ant 1, where and do nothing when the > condition is > > false. For example: > > > > ant -Dsome-prop=true > > > > > > > > > > > > => some-prop is 'true' > > > > or > > > > > > > > > > > > > > > > > > > > => some-prop is 'true' > > > > Different isn't necessarily bad, though. > > > > How does this will comply with inmutability of properties? > What if the first is false and the second is true? > I think we're talking about the same thing. What I was trying to say: If we go with immutable properties, then should never try to change the value of a property if it has already been set. If we go with mutable properties (as we have in myrmidon - for the time being at least), then should always set the property to the result of the test. and, separately If we go with the 'is set' test for conditionals (if="", etc), then should set the property to 'true' (or any value) when the test is true, and unset the property when the test is false. If we go with the 'is set and value is not false' test for conditionals, then should set the property to 'true' when the test is true, and 'false' when the test is false. So, combining these: For an ant 1 style setup, with immutable properties and 'is set' test: test true => set property to 'true' if not already set test false => do nothing For a myrmidon style setup, with mutable properties and 'is set and not false' test: test true => set property to 'true' test false => set property to 'false' > See, all these things need to work toguether. Otherwise > 3 months after ANT2 is out the whole thing starts to unravell. > One of the advantages of having mutable properties, is that you can combine and to get any behaviour you like, if what does isn't what you like. is simply a convenience task in this case. Combine that with polymorphic types, and the whole issue becomes far less critical. Then it doesn't matter as much if we get the convenience forms wrong, when you have the flexibility to put together any behaviour you like. But it is a good point. I think the only really effective way to figure out whether we have things right or not, is to actually use the thing to do builds. That means a long release cycle. We can keep doing alphas and betas until we get it right. And there's no reason for ant 1 releases to stop during that time. > > > > In myrmidon, we have done away with the "if" and "unless" attributes for > > altogether, now that we have an task. So now the > answer to > > the question 'do we test is-set/is-not-set or > is-true/is-not-true?' is: It > > doesn't matter - let the build file writer tell us what they want. > > > > How about the "if" and "unless" attributes in which is > actually used in ANT's own build file. > Still there. We're also experimenting with using selectors as an alternative. And the ant1 and are still there and work the same as they always have, thanks to the very cool ant1compat antlib. > > As it has been put forth before, it would be interesting to > explore treating "if/unless" > the same generic way we treat "id" today. That is, you can attach > it to any node > and IntrospectionHelper will add it or not depending on whether > it is fulfilled > or not. > Definitely something I'd like to try out with myrmidon. Adam -- To unsubscribe, e-mail: For additional commands, e-mail: