Quantcast

if/unless Attributes

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

if/unless Attributes

Stefan Bodewig
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if/unless Attributes

Matt Benson


--- On Thu, 9/24/09, Stefan Bodewig <[hidden email]> wrote:

> From: Stefan Bodewig <[hidden email]>
> Subject: if/unless Attributes
> To: [hidden email]
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if/unless Attributes

Dominique Devienne-2
On Thu, Sep 24, 2009 at 9:04 AM, Matt Benson <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if/unless Attributes

Dominique Devienne-2
In reply to this post by Stefan Bodewig
On Thu, Sep 24, 2009 at 6:32 AM, Stefan Bodewig <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if/unless Attributes

Jesse Glick
In reply to this post by Stefan Bodewig
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if/unless Attributes

Matt Benson
In reply to this post by Dominique Devienne-2


--- On Thu, 9/24/09, Dominique Devienne <[hidden email]> wrote:

> From: Dominique Devienne <[hidden email]>
> Subject: Re: if/unless Attributes
> To: "Ant Developers List" <[hidden email]>
> Date: Thursday, September 24, 2009, 9:12 AM
> On Thu, Sep 24, 2009 at 9:04 AM, Matt
> Benson <[hidden email]>
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if/unless Attributes

Stefan Bodewig
In reply to this post by Dominique Devienne-2
On 2009-09-24, Dominique Devienne <[hidden email]> wrote:

> On Thu, Sep 24, 2009 at 6:32 AM, Stefan Bodewig <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if/unless Attributes

Matt Benson


--- On Thu, 9/24/09, Stefan Bodewig <[hidden email]> wrote:

> From: Stefan Bodewig <[hidden email]>
> Subject: Re: if/unless Attributes
> To: [hidden email]
> Date: Thursday, September 24, 2009, 10:42 AM
> On 2009-09-24, Dominique Devienne
> <[hidden email]>
> wrote:
>
> > On Thu, Sep 24, 2009 at 6:32 AM, Stefan Bodewig <[hidden email]>
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if/unless Attributes

Stefan Bodewig
In reply to this post by Matt Benson
On 2009-09-24, Matt Benson <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if/unless Attributes

Stefan Bodewig
In reply to this post by Dominique Devienne-2
On 2009-09-24, Dominique Devienne <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if/unless Attributes

Stefan Bodewig
In reply to this post by Jesse Glick
On 2009-09-24, Jesse Glick <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if/unless Attributes

Stefan Bodewig
On 2009-09-24, Stefan Bodewig <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if/unless Attributes

Dominique Devienne-2
In reply to this post by Stefan Bodewig
On Thu, Sep 24, 2009 at 10:46 AM, Stefan Bodewig <[hidden email]> wrote:
> On 2009-09-24, Dominique Devienne <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if/unless Attributes

Peter Reilly-2
In reply to this post by Stefan Bodewig
using <target name="x" if="${foo}">
seems to be very very strange..


Peter



On Thu, Sep 24, 2009 at 5:09 PM, Stefan Bodewig <[hidden email]> wrote:

> On 2009-09-24, Stefan Bodewig <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if/unless Attributes

Matt Benson
In reply to this post by Dominique Devienne-2


--- On Thu, 9/24/09, Dominique Devienne <[hidden email]> wrote:

> From: Dominique Devienne <[hidden email]>
> Subject: Re: if/unless Attributes
> To: "Ant Developers List" <[hidden email]>
> Date: Thursday, September 24, 2009, 12:15 PM
> On Thu, Sep 24, 2009 at 10:46 AM,
> Stefan Bodewig <[hidden email]>
> wrote:
> > On 2009-09-24, Dominique Devienne <[hidden email]>
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


     

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if/unless Attributes

Matt Benson
In reply to this post by Peter Reilly-2


--- On Thu, 9/24/09, Peter Reilly <[hidden email]> wrote:

> From: Peter Reilly <[hidden email]>
> Subject: Re: if/unless Attributes
> To: "Ant Developers List" <[hidden email]>
> 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 <[hidden email]>
> wrote:
> > On 2009-09-24, Stefan Bodewig <[hidden email]>
> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if/unless Attributes

Stefan Bodewig
On 2009-09-24, Matt Benson <[hidden email]> wrote:

> --- On Thu, 9/24/09, Peter Reilly <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if/unless Attributes

Jesse Glick
In reply to this post by Stefan Bodewig
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if/unless Attributes

Dominique Devienne-2
On Fri, Sep 25, 2009 at 8:16 AM, Jesse Glick <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: if/unless Attributes

Matt Benson


--- On Fri, 9/25/09, Dominique Devienne <[hidden email]> wrote:

> From: Dominique Devienne <[hidden email]>
> Subject: Re: if/unless Attributes
> To: "Ant Developers List" <[hidden email]>
> Date: Friday, September 25, 2009, 9:31 AM
> On Fri, Sep 25, 2009 at 8:16 AM,
> Jesse Glick <[hidden email]>
> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


     

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

12
Loading...