--- On Thu, 9/24/09, Stefan Bodewig <bode...@apache.org> wrote:
> From: Stefan Bodewig <bode...@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-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org
