ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <j_a_fernan...@yahoo.com>
Subject Re: suggestion for if/unless syntax change
Date Sat, 23 Mar 2002 12:51:41 GMT
From: "Adam Murdoch" <adammurdoch_ml@yahoo.com>

> 
> > From: Jose Alberto Fernandez [mailto:j_a_fernandez@yahoo.com]
> >
> > 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?

See, all these things need to work toguether. Otherwise 
3 months after ANT2 is out the whole thing starts to unravell.

> 
> >
> > Notice I am talking about the "if" attribute, not the <if> task.
> > You cannot change
> > the implementation of it (I do not think).
> >
> 
> Sure you can.  You just need to come up with some way to describe which
> condition implementation to use.  Something like:
> 
> <target>
>   <my-homemade-condition someprop="blah"/>
>   <task/>
>   <task/>
> </target>
> 
> And make
> 
> <target if="someprop">
>   ...
> </target>
> 
> shorthand for
> 
> <target>
>   <is-set property="someprop"/>
>   ...
> </target>
> 
> 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.

To certain extend, "if/unless" is a very powerful concept to allow conditional
addition of a particular element from the XML tree.

This is different from <target if='...'> because in this case it is the content of target
that gets included/excluded given the condition. This is why your rewriting rule
works.

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. 

It would allow for quite a simplification of the code. But I know, it is controvertial.

Jose Alberto



--
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