ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Murdoch" <>
Subject RE: suggestion for if/unless syntax change
Date Sat, 23 Mar 2002 23:54:39 GMT

> -----Original Message-----
> From: Jose Alberto Fernandez []
> 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 []
> > >
> > > Humm. I think we are mixing two different things: (1) "if"
> > > attribute of <target>, <exclude>, etc;
> > > and (2) <if> 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
> > > <available> 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, <condition> probably should do
> something when
> > the condition is false.  This would be different to the way
> things work in
> > ant 1, where <available> and <condition> do nothing when the
> condition is
> > false.  For example:
> >
> > ant -Dsome-prop=true
> >
> > <condition property="some-prop">
> >   <some-false-condition/>
> > </condition>
> >
> > => some-prop is 'true'
> >
> > or
> >
> > <condition property="some-prop">
> >   <some-true-condition/>
> > </condition>
> >
> > <condition property="some-prop">
> >   <some-false-condition/>
> > </condition>
> >
> > => some-prop is 'true'
> >
> > Different isn't necessarily bad, though.
> >
> How does this will comply with inmutability of properties?
> What if the first <condition> 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 <condition> 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 <condition> 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
<condition> 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 <condition> 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
<if> and <property> to get any behaviour you like, if what <condition> does
isn't what you like.   <condition> is simply a convenience task in this

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
> > <target> altogether, now that we have an <if> 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 <exclude> which is
> actually used in ANT's own build file.

Still there.  We're also experimenting with using selectors as an

And the ant1 <fileset> and <patternset> 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.


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

View raw message