You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Stefan Bodewig <bo...@apache.org> on 2009/09/24 13:32:20 UTC
if/unless Attributes
Hi,
the if/unless attributes for target have changes slightly in that they
now may use PropertyHelpers. I.e.
<target if="${foo}">
will not be executed if ${foo} happens to expand to a Boolean instance
with a booleanValue() of "false" and likewise
<target unless="${foo}">
will be executed in that case. So far this hasn't been documented, but
I'll do so shortly.
Some other places where we use if/unless like the <fail> task haven't
been changed and I think it would be good to make all places consistent.
Unfortunately I don't see an easy way to do that since the Strings sent
to the attributes of tasks and types are property expanded (unlike the
attributes of target) and in the case I've described the tasks won't see
${foo} anymore but the String "false" (via the implicit Object => String
conversion of PropertyHelper)
If we changed the setters to accept an Object arg this might work - but
see the comment in Property.java:
/* the following method is first in source so IH will pick it up first:
* Hopefully we'll never get any classes compiled by wise-guy compilers that behave otherwise...
*/
Do we want to rely on this?
And a related question: we currently don't provide any PropertyEvaluator
that would create Booleans. Do we want to provide something like
${isTrue:foo} that created Boolean.TRUE if Project.toBoolean(${foo}) was
true? Or should something like this go into the props Antlib?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: if/unless Attributes
Posted by Matt Benson <gu...@yahoo.com>.
--- On Fri, 9/25/09, Dominique Devienne <dd...@gmail.com> wrote:
> From: Dominique Devienne <dd...@gmail.com>
> Subject: Re: if/unless Attributes
> To: "Ant Developers List" <de...@ant.apache.org>
> Date: Friday, September 25, 2009, 9:31 AM
> On Fri, Sep 25, 2009 at 8:16 AM,
> Jesse Glick <je...@sun.com>
> wrote:
> > Refined proposal:
> >
> > 1. Make <target> evaluate if/unless attributes
> (just before deciding whether
> > or not to run the target).
> >
> > 2. Introduce Project.isTrueOrSet(String val) which
> would return true if
> > toBoolean(val) || getProperty(val) != null.
> >
> > 3. Call iTOS from <target>, <fail>, etc. -
> anything with if/unless
> > attributes with the standard meaning.
> >
> > Now <target if="doSomething"> would behave as
> before, for better or worse.
> > But you could also write <target
> if="${doSomething}"> and it would work as
> > most novice Ant users would expect: run the target if
> doSomething is defined
> > but also set to 'true' (or 'on' or 'yes'). Similarly
> for <fail> and friends.
>
> I like Jesse's proposal. It fits well with the principle of
> least
> surprise, on both
> the new user front, since ${foo} is correctly interpreted
> in boolean cases, and
> for existing users too, since the existing behavior of
> testing
> property existence
> remains. So +1 from me. Anything more is not really needed
> IMHO. --DD
I can certainly live with this. I am ambivalent. :)
-Matt
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: if/unless Attributes
Posted by Dominique Devienne <dd...@gmail.com>.
On Fri, Sep 25, 2009 at 8:16 AM, Jesse Glick <je...@sun.com> wrote:
> Refined proposal:
>
> 1. Make <target> evaluate if/unless attributes (just before deciding whether
> or not to run the target).
>
> 2. Introduce Project.isTrueOrSet(String val) which would return true if
> toBoolean(val) || getProperty(val) != null.
>
> 3. Call iTOS from <target>, <fail>, etc. - anything with if/unless
> attributes with the standard meaning.
>
> Now <target if="doSomething"> would behave as before, for better or worse.
> But you could also write <target if="${doSomething}"> and it would work as
> most novice Ant users would expect: run the target if doSomething is defined
> but also set to 'true' (or 'on' or 'yes'). Similarly for <fail> and friends.
I like Jesse's proposal. It fits well with the principle of least
surprise, on both
the new user front, since ${foo} is correctly interpreted in boolean cases, and
for existing users too, since the existing behavior of testing
property existence
remains. So +1 from me. Anything more is not really needed IMHO. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: if/unless Attributes
Posted by Jesse Glick <je...@sun.com>.
Stefan Bodewig wrote:
>> Should there be an entry in WHATSNEW, and updates to the manual?
>
> Absolutely. Unfortunately I'm pretty much maxed out for the next few
> weeks and struggle to get some open source coding time.
I can try to document it then.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: if/unless Attributes
Posted by Stefan Bodewig <bo...@apache.org>.
On 2009-11-04, Jesse Glick <je...@sun.com> wrote:
> So it looks like all this is now implemented
Yep, including tests.
> Should there be an entry in WHATSNEW, and updates to the manual?
Absolutely. Unfortunately I'm pretty much maxed out for the next few
weeks and struggle to get some open source coding time.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: if/unless Attributes
Posted by Jesse Glick <je...@sun.com>.
Stefan Bodewig wrote:
>> 2. Introduce Project.isTrueOrSet(String val) which would return true
>> if toBoolean(val) || getProperty(val) != null.
>
> PropertyHelper likely is the better place for this, otherwise I agree,
> the code has to move out of Target and needs the described semantics. [...]
>
>> 3. Call iTOS from <target>, <fail>, etc. - anything with if/unless
>> attributes with the standard meaning.
>
> Sounds good.
So it looks like all this is now implemented - nice! Should there be an entry in WHATSNEW, and updates to the manual?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: if/unless Attributes
Posted by Stefan Bodewig <bo...@apache.org>.
On 2009-09-25, Jesse Glick <je...@sun.com> wrote:
> Refined proposal:
> 1. Make <target> evaluate if/unless attributes (just before deciding
> whether or not to run the target).
it already does (and has done so in the past).
> 2. Introduce Project.isTrueOrSet(String val) which would return true
> if toBoolean(val) || getProperty(val) != null.
PropertyHelper likely is the better place for this, otherwise I agree,
the code has to move out of Target and needs the described semantics.
Actually your toBoolean is not really boolean but follows a ternary
logic of true, false, "some other value including null". Maybe
something like
Boolean toBoolean(Object)
and you'd want
if toBoolean(val) == Booolean.TRUE ||
(toBoolean(val) != Boolean.FALSE && getProperty(val) != null)
so a value of "false" would really mean false.
The code in Target almost does that, with the exception that the
equivalent of toBoolean only works if val is a Boolean instance right
now.
> 3. Call iTOS from <target>, <fail>, etc. - anything with if/unless
> attributes with the standard meaning.
Sounds good.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: if/unless Attributes
Posted by Jesse Glick <je...@sun.com>.
Stefan Bodewig wrote:
>> A modest suggestion: why don't we just make PropertyHelper treat
>> (String) "false" as (Boolean) false, and <target> likewise?
>
> I wouldn't do that in PropertyHelper
Sorry, what I wrote did not make sense.
> but would think it may be a sensible choice for target.
What I meant was for if/unless on <target> and any tasks or types or subelements like <fail>, <include>, etc. which have a similar attribute pair.
> <target if="doSomething"/>
>
> still wouldn't expand the property, you'd have to write
>
> <target if="${doSomething}"/>
>
> instead.
Which is more intuitive anyway; people are accustomed to always writing uses of properties with ${...} and it is confusing to have to omit the expansion only in this
handful of cases.
Refined proposal:
1. Make <target> evaluate if/unless attributes (just before deciding whether or not to run the target).
2. Introduce Project.isTrueOrSet(String val) which would return true if toBoolean(val) || getProperty(val) != null.
3. Call iTOS from <target>, <fail>, etc. - anything with if/unless attributes with the standard meaning.
Now <target if="doSomething"> would behave as before, for better or worse. But you could also write <target if="${doSomething}"> and it would work as most novice Ant
users would expect: run the target if doSomething is defined but also set to 'true' (or 'on' or 'yes'). Similarly for <fail> and friends.
Incompatibility would be restricted to some pathological cases such as:
<target if="true"><echo>used to run only if -Dtrue=whatever, now will always run</echo></target>
<property name="$${weird}" value="whatever"/>
<target if="${weird}"><echo>used to run, now will not unless -Dweird=true</echo></target>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: if/unless Attributes
Posted by Stefan Bodewig <bo...@apache.org>.
On 2009-09-24, Matt Benson <gu...@yahoo.com> wrote:
> --- On Thu, 9/24/09, Peter Reilly <pe...@gmail.com> wrote:
>> using <target name="x" if="${foo}">
>> seems to be very very strange..
> Maybe it seems that way, but taking into account you'd have to be
> deliberately using propertyhelper delegates to make proper use of
> this, it might look like:
> <target name="x" if="${boolean:${do-x}}" unless="${boolean:${skip-x}}">
> <...>
> </target>
<target name="x" if="${||(${boolean:${arg1}},${boolean:${arg2}})}">
yes, it looks unwieldy.
It would be possible to remove the outer ${} so Matt's example could
become
if="boolean:${do-x}"
This can be done without breaking backwards compatibility too much but
leaves us with a place where Ant suddenly expands properties without ${}
syntax - I'm not convinced this would be a good idea.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: if/unless Attributes
Posted by Matt Benson <gu...@yahoo.com>.
--- On Thu, 9/24/09, Peter Reilly <pe...@gmail.com> wrote:
> From: Peter Reilly <pe...@gmail.com>
> Subject: Re: if/unless Attributes
> To: "Ant Developers List" <de...@ant.apache.org>
> Date: Thursday, September 24, 2009, 12:36 PM
> using <target name="x"
> if="${foo}">
> seems to be very very strange..
>
Maybe it seems that way, but taking into account you'd have to be deliberately using propertyhelper delegates to make proper use of this, it might look like:
<target name="x" if="${boolean:${do-x}}" unless="${boolean:${skip-x}}">
<...>
</target>
-Matt
>
> Peter
>
>
>
> On Thu, Sep 24, 2009 at 5:09 PM, Stefan Bodewig <bo...@apache.org>
> wrote:
> > On 2009-09-24, Stefan Bodewig <bo...@apache.org>
> wrote:
> >
> >> <target if="${foo}"/>
> >
> >> will only be executed if a property named ${foo}
> exists (unexpanded) -
> >> in Ant 1.7.1. and Ant 1.8.0 - or if expanding
> ${foo} returns something
> >> that equals Boolean.TRUE (Ant 1.8.0 only).
> >
> > This part is false, I just re-read the code. It will
> look up a property
> > named like the expansion of ${foo} - and it's been
> that way in 1.7.1 as
> > well.
> >
> > This doesn't change the rest of what I wrote, you'd
> still need
> > <target if="${foo}"/> if you wanted to skip a
> target if foo evaluated to
> > "false".
> >
> > Stefan
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: if/unless Attributes
Posted by Peter Reilly <pe...@gmail.com>.
using <target name="x" if="${foo}">
seems to be very very strange..
Peter
On Thu, Sep 24, 2009 at 5:09 PM, Stefan Bodewig <bo...@apache.org> wrote:
> On 2009-09-24, Stefan Bodewig <bo...@apache.org> wrote:
>
>> <target if="${foo}"/>
>
>> will only be executed if a property named ${foo} exists (unexpanded) -
>> in Ant 1.7.1. and Ant 1.8.0 - or if expanding ${foo} returns something
>> that equals Boolean.TRUE (Ant 1.8.0 only).
>
> This part is false, I just re-read the code. It will look up a property
> named like the expansion of ${foo} - and it's been that way in 1.7.1 as
> well.
>
> This doesn't change the rest of what I wrote, you'd still need
> <target if="${foo}"/> if you wanted to skip a target if foo evaluated to
> "false".
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: if/unless Attributes
Posted by Stefan Bodewig <bo...@apache.org>.
On 2009-09-24, Stefan Bodewig <bo...@apache.org> wrote:
> <target if="${foo}"/>
> will only be executed if a property named ${foo} exists (unexpanded) -
> in Ant 1.7.1. and Ant 1.8.0 - or if expanding ${foo} returns something
> that equals Boolean.TRUE (Ant 1.8.0 only).
This part is false, I just re-read the code. It will look up a property
named like the expansion of ${foo} - and it's been that way in 1.7.1 as
well.
This doesn't change the rest of what I wrote, you'd still need
<target if="${foo}"/> if you wanted to skip a target if foo evaluated to
"false".
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: if/unless Attributes
Posted by Stefan Bodewig <bo...@apache.org>.
On 2009-09-24, Jesse Glick <je...@sun.com> wrote:
> Stefan Bodewig wrote:
>> I don't see an easy way to [make <fail> work] since the Strings sent
>> to the attributes of tasks and types are property expanded (unlike the
>> attributes of target) and in the case I've described the tasks won't see
>> ${foo} anymore but the String "false" (via the implicit Object => String
>> conversion of PropertyHelper)
>> [...]
>> we currently don't provide any PropertyEvaluator
>> that would create Booleans. Do we want to provide something like
>> ${isTrue:foo} that created Boolean.TRUE if Project.toBoolean(${foo}) was
>> true?
> A modest suggestion: why don't we just make PropertyHelper treat
> (String) "false" as (Boolean) false, and <target> likewise?
I wouldn't do that in PropertyHelper, but would think it may be a
sensible choice for target.
One thing to note (at least of the current implementation) is that there
is a difference between the is-set? and is-true? logic in these
attributes:
<target if="foo"/>
will only be executed if a property named foo exists, regardless of its
value. This is the same for Ant 1.8.0 and 1.7.1.
<target if="${foo}"/>
will only be executed if a property named ${foo} exists (unexpanded) -
in Ant 1.7.1. and Ant 1.8.0 - or if expanding ${foo} returns something
that equals Boolean.TRUE (Ant 1.8.0 only).
As soon as we talk about task/type attributes things change since these
attributes are always subject to property expansion.
<fail if="foo"/> has the same semantics as <target if="foo"/> but for
<fail if="${foo}"/> ${foo} gets expanded when looking up the property
name (this difference has been ever since <target> and <include> both
had if attributes, don't remember which came first).
Back to your suggestion
> Then we would not need any new magical evaluators and most people
> would never need to use the <istrue> condition. Passing
> -DdoSomething=false would actually do what every developer new to Ant
> expects it to do (as opposed to Ant's current behavior which is quite
> surprising and inconvenient).
No it wouldn't since
<target if="doSomething"/>
still wouldn't expand the property, you'd have to write
<target if="${doSomething}"/>
instead.
By tweaking the implementation of Target#testIfAllows to use getProperty
instead of parseProperties when testing for the Boolean this would work,
but it would be the only place in Ant where properties get expanded
without using the ${} syntax.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: if/unless Attributes
Posted by Jesse Glick <je...@sun.com>.
Stefan Bodewig wrote:
> I don't see an easy way to [make <fail> work] since the Strings sent
> to the attributes of tasks and types are property expanded (unlike the
> attributes of target) and in the case I've described the tasks won't see
> ${foo} anymore but the String "false" (via the implicit Object => String
> conversion of PropertyHelper)
>
> [...]
>
> we currently don't provide any PropertyEvaluator
> that would create Booleans. Do we want to provide something like
> ${isTrue:foo} that created Boolean.TRUE if Project.toBoolean(${foo}) was
> true?
A modest suggestion: why don't we just make PropertyHelper treat (String) "false" as (Boolean) false, and <target> likewise? Then we would not need any new magical
evaluators and most people would never need to use the <istrue> condition. Passing -DdoSomething=false would actually do what every developer new to Ant expects it to do
(as opposed to Ant's current behavior which is quite surprising and inconvenient).
Maybe this is a bit too Perlish for some people, but Ant already forces you to stringify properties and that's what build scripts (and their *.properties configuration)
are expecting.
For the three scripts out there which intentionally rely on "false" being true, the old behavior could be reenabled with a compatibility property set on the project which
would issue warnings when it needed to be used. Any such scripts could easily be made to avoid this assumption (while retaining 1.7.x compatibility):
<target name="run" if="doSomething">
<echo>runs even if -DdoSomething=false!</echo>
</target>
=>
<condition property="doSomething.set"><isset property="doSomething"/></condition>
<target name="run" if="doSomething.set">
<echo>still runs with -DdoSomething=false but now more obvious</echo>
</target>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: if/unless Attributes
Posted by Matt Benson <gu...@yahoo.com>.
--- On Thu, 9/24/09, Stefan Bodewig <bo...@apache.org> wrote:
> From: Stefan Bodewig <bo...@apache.org>
> Subject: Re: if/unless Attributes
> To: dev@ant.apache.org
> Date: Thursday, September 24, 2009, 10:42 AM
> On 2009-09-24, Dominique Devienne
> <dd...@gmail.com>
> wrote:
>
> > On Thu, Sep 24, 2009 at 6:32 AM, Stefan Bodewig <bo...@apache.org>
> wrote:
> >> the if/unless attributes for target have changes
> slightly in that they
> >> now may use PropertyHelpers. I.e.
>
> >> <target if="${foo}">
>
> >> will not be executed if ${foo} happens to expand
> to a Boolean instance
> >> with a booleanValue() of "false" and likewise
>
> >> <target unless="${foo}">
>
> >> will be executed in that case. So far this
> hasn't been documented, but
> >> I'll do so shortly.
>
> > That's a pretty big change.
>
> As is the changed PropertyHelper API. In fact Matt
> added that more or
> less at the same time. I just stumbled over it while
> trying to
> understand PropertyHelper 8-)
>
> > What's the exact semantic? Does it depend on the type
> returned, like
> > Boolean, Object, String.
>
> Yes, it only applies to Boolean.
>
> > For String, does that fall back to assuming it's a
> property name that
> > must be checked for existence?
>
> the logic in target is:
>
> * try to evaluate the argument (${foo}) as a property
>
> * if the result is a Boolean, use its booleanValue
>
> * if it is not a Boolean, ignore it completely but instead
> check whether
> a property of the argument's name exists - just like
> in Ant 1.7.1 this
> does not expand ${foo} so it would look literally
> look up a property
> named ${foo}.
>
> > What's the exact timing of the evaluation? Before or
> after depends' targets?
>
> The same as before - at the start of Target#execute, i.e.
> it doesn't
> factor into depends at all.
>
I'm discreet that way. ;)
-Matt
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: if/unless Attributes
Posted by Stefan Bodewig <bo...@apache.org>.
On 2009-09-24, Dominique Devienne <dd...@gmail.com> wrote:
> On Thu, Sep 24, 2009 at 6:32 AM, Stefan Bodewig <bo...@apache.org> wrote:
>> the if/unless attributes for target have changes slightly in that they
>> now may use PropertyHelpers. I.e.
>> <target if="${foo}">
>> will not be executed if ${foo} happens to expand to a Boolean instance
>> with a booleanValue() of "false" and likewise
>> <target unless="${foo}">
>> will be executed in that case. So far this hasn't been documented, but
>> I'll do so shortly.
> That's a pretty big change.
As is the changed PropertyHelper API. In fact Matt added that more or
less at the same time. I just stumbled over it while trying to
understand PropertyHelper 8-)
> What's the exact semantic? Does it depend on the type returned, like
> Boolean, Object, String.
Yes, it only applies to Boolean.
> For String, does that fall back to assuming it's a property name that
> must be checked for existence?
the logic in target is:
* try to evaluate the argument (${foo}) as a property
* if the result is a Boolean, use its booleanValue
* if it is not a Boolean, ignore it completely but instead check whether
a property of the argument's name exists - just like in Ant 1.7.1 this
does not expand ${foo} so it would look literally look up a property
named ${foo}.
> What's the exact timing of the evaluation? Before or after depends' targets?
The same as before - at the start of Target#execute, i.e. it doesn't
factor into depends at all.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: if/unless Attributes
Posted by Dominique Devienne <dd...@gmail.com>.
On Thu, Sep 24, 2009 at 6:32 AM, Stefan Bodewig <bo...@apache.org> wrote:
> the if/unless attributes for target have changes slightly in that they
> now may use PropertyHelpers. I.e.
>
> <target if="${foo}">
>
> will not be executed if ${foo} happens to expand to a Boolean instance
> with a booleanValue() of "false" and likewise
>
> <target unless="${foo}">
>
> will be executed in that case. So far this hasn't been documented, but
> I'll do so shortly.
That's a pretty big change.
What's the exact semantic? Does it depend on the type returned, like
Boolean, Object, String. For String, does that fall back to assuming
it's a property name
that must be checked for existence?
What's the exact timing of the evaluation? Before or after depends' targets?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: if/unless Attributes
Posted by Matt Benson <gu...@yahoo.com>.
--- On Thu, 9/24/09, Dominique Devienne <dd...@gmail.com> wrote:
> From: Dominique Devienne <dd...@gmail.com>
> Subject: Re: if/unless Attributes
> To: "Ant Developers List" <de...@ant.apache.org>
> Date: Thursday, September 24, 2009, 9:12 AM
> On Thu, Sep 24, 2009 at 9:04 AM, Matt
> Benson <gu...@yahoo.com>
> wrote:
> >> And a related question: we currently don't provide
> any
> >> PropertyEvaluator
> >> that would create Booleans. Do we want to
> provide
> >> something like
> >> ${isTrue:foo} that created Boolean.TRUE if
> >> Project.toBoolean(${foo}) was
> >> true? Or should something like this go into the
> props
> >> Antlib?
> >
> > Along these lines, I was just in the process of coding
> up a BooleanEvaluator for the props antlib--I was just
> thinking e.g. ${boolean:on} and delegate to
> Project.toBoolean(String). If used in conjunction with the
> NestedPropertyExpander, ${boolean:${foo}} should return true
> given <property name="foo" value="[on|yes|true]" />.
> In fact I'd probably include that last sentence verbatim
> in the documentation. Note that this is mostly useful for
> overloaded API areas as boolean task properties will still
> go through InputHelper and be converted as usual.
> >
> > WDYT?
>
> we have ${toString:foo}, we might as well call it
> ${toBoolean:foo} to
> be consistent, and this also maps cleanly to the Project
> method that
> implements the logic.
This sounds like a sensible choice if I commit this--it's done and tested.
-Matt
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: if/unless Attributes
Posted by Matt Benson <gu...@yahoo.com>.
--- On Thu, 9/24/09, Dominique Devienne <dd...@gmail.com> wrote:
> From: Dominique Devienne <dd...@gmail.com>
> Subject: Re: if/unless Attributes
> To: "Ant Developers List" <de...@ant.apache.org>
> Date: Thursday, September 24, 2009, 12:15 PM
> On Thu, Sep 24, 2009 at 10:46 AM,
> Stefan Bodewig <bo...@apache.org>
> wrote:
> > On 2009-09-24, Dominique Devienne <dd...@gmail.com>
> wrote:
> >> we have ${toString:foo}, we might as well call it
> ${toBoolean:foo} to
> >> be consistent,
> >
> > toString applies to project references, not
> properties, so they would
> > not be as symmetric as they look.
>
> True. Which makes me think ${toBoolean:ref} would / should
> evaluate to true or
> false when the reference is defined or not. --DD
Okay, the evaluator *I* am talking about :) will evaluate a string using Project.toBoolean(String) (if you want to evaluate another property use the NestedPropertyExpander and go for it). So, very basically, what I currently have is ${boolean:[on|yes|true]} evaluates to Boolean.TRUE.
Alternatives:
${boolean:true}
${toBoolean:true} //asymmetric to toString:ref
${isTrue:true}
${booleanValue:true}
...others?
-Matt
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: if/unless Attributes
Posted by Dominique Devienne <dd...@gmail.com>.
On Thu, Sep 24, 2009 at 10:46 AM, Stefan Bodewig <bo...@apache.org> wrote:
> On 2009-09-24, Dominique Devienne <dd...@gmail.com> wrote:
>> we have ${toString:foo}, we might as well call it ${toBoolean:foo} to
>> be consistent,
>
> toString applies to project references, not properties, so they would
> not be as symmetric as they look.
True. Which makes me think ${toBoolean:ref} would / should evaluate to true or
false when the reference is defined or not. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: if/unless Attributes
Posted by Stefan Bodewig <bo...@apache.org>.
On 2009-09-24, Dominique Devienne <dd...@gmail.com> wrote:
> we have ${toString:foo}, we might as well call it ${toBoolean:foo} to
> be consistent,
toString applies to project references, not properties, so they would
not be as symmetric as they look.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: if/unless Attributes
Posted by Dominique Devienne <dd...@gmail.com>.
On Thu, Sep 24, 2009 at 9:04 AM, Matt Benson <gu...@yahoo.com> wrote:
>> And a related question: we currently don't provide any
>> PropertyEvaluator
>> that would create Booleans. Do we want to provide
>> something like
>> ${isTrue:foo} that created Boolean.TRUE if
>> Project.toBoolean(${foo}) was
>> true? Or should something like this go into the props
>> Antlib?
>
> Along these lines, I was just in the process of coding up a BooleanEvaluator for the props antlib--I was just thinking e.g. ${boolean:on} and delegate to Project.toBoolean(String). If used in conjunction with the NestedPropertyExpander, ${boolean:${foo}} should return true given <property name="foo" value="[on|yes|true]" />. In fact I'd probably include that last sentence verbatim in the documentation. Note that this is mostly useful for overloaded API areas as boolean task properties will still go through InputHelper and be converted as usual.
>
> WDYT?
we have ${toString:foo}, we might as well call it ${toBoolean:foo} to
be consistent, and this also maps cleanly to the Project method that
implements the logic.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: if/unless Attributes
Posted by Stefan Bodewig <bo...@apache.org>.
On 2009-09-24, Matt Benson <gu...@yahoo.com> wrote:
> Along these lines, I was just in the process of coding up a
> BooleanEvaluator for the props antlib--I was just thinking
> e.g. ${boolean:on} and delegate to Project.toBoolean(String). If used
> in conjunction with the NestedPropertyExpander, ${boolean:${foo}}
> should return true given
> <property name="foo" value="[on|yes|true]" />.
Yes, when you have NestedPropertyExpander at hand, this makes much more
sense.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: if/unless Attributes
Posted by Matt Benson <gu...@yahoo.com>.
--- On Thu, 9/24/09, Stefan Bodewig <bo...@apache.org> wrote:
> From: Stefan Bodewig <bo...@apache.org>
> Subject: if/unless Attributes
> To: dev@ant.apache.org
> Date: Thursday, September 24, 2009, 6:32 AM
> Hi,
>
> the if/unless attributes for target have changes slightly
> in that they
> now may use PropertyHelpers. I.e.
>
> <target if="${foo}">
>
> will not be executed if ${foo} happens to expand to a
> Boolean instance
> with a booleanValue() of "false" and likewise
>
> <target unless="${foo}">
>
> will be executed in that case. So far this hasn't
> been documented, but
> I'll do so shortly.
>
> Some other places where we use if/unless like the
> <fail> task haven't
> been changed and I think it would be good to make all
> places consistent.
>
> Unfortunately I don't see an easy way to do that since the
> Strings sent
> to the attributes of tasks and types are property expanded
> (unlike the
> attributes of target) and in the case I've described the
> tasks won't see
> ${foo} anymore but the String "false" (via the implicit
> Object => String
> conversion of PropertyHelper)
>
> If we changed the setters to accept an Object arg this
> might work - but
> see the comment in Property.java:
>
> /* the following method is first in source so
> IH will pick it up first:
> * Hopefully we'll never get any
> classes compiled by wise-guy compilers that behave
> otherwise...
> */
>
> Do we want to rely on this?
>
> And a related question: we currently don't provide any
> PropertyEvaluator
> that would create Booleans. Do we want to provide
> something like
> ${isTrue:foo} that created Boolean.TRUE if
> Project.toBoolean(${foo}) was
> true? Or should something like this go into the props
> Antlib?
>
Along these lines, I was just in the process of coding up a BooleanEvaluator for the props antlib--I was just thinking e.g. ${boolean:on} and delegate to Project.toBoolean(String). If used in conjunction with the NestedPropertyExpander, ${boolean:${foo}} should return true given <property name="foo" value="[on|yes|true]" />. In fact I'd probably include that last sentence verbatim in the documentation. Note that this is mostly useful for overloaded API areas as boolean task properties will still go through InputHelper and be converted as usual.
WDYT?
-Matt
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org