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 Fri, 22 Mar 2002 01:47:36 GMT

> -----Original Message-----
> From: Diane Holt []
> Sent: Friday, 22 March 2002 7:27 AM
> To: Ant Developers List
> Subject: RE: suggestion for if/unless syntax change
> --- Adam Murdoch <> wrote:
> > Here's how the test gets evaluated:
> >
> > property not set => false
> > property set to 'false' => false
> > property set to anything other than 'false' => true
> Personally, I'm not sure I like the idea of a property's value being
> evaluated when it's just the property's name being specified (eg., "foo"),
> not a reference to the property's value (eg., "${foo}").

It really does depend on where the property name is being used.  Sometimes
you want the property to be dereferenced, sometimes not.  What we want to
aim for, is to do away with a fixed policy for things like how conditions
get evaluated, and let the build file writer decide and explicitly tell ant
what they want.

This is where polymorphic data types really become useful.  Don't like the
way something works?  Swap in a different implementation.  For example, in
myrmidon we provide a bunch of condition implementations, and you can swap
in one of these (or you own), in the places where the standard
is-set/is-not-set test isn't appropriate.  For example, we have conditions
like :

  <is-set property="name"> (the ant 1 style test)
  <is-true property="name"> (the myrmidon style test)
  <and>..</and>, <or>..</or>, <not>..</not>
  plus the ant 1 conditions from the <condition> task.

It is very easy to add your own specialised condition implementations, too -
import from an antlib, or <type-def> in your build file:

<type-def type="condition" name="my-condition" classname="..."/>

  <my-condition some-prop="foo"/>


<fileset dir="..">
      <name pattern="**/*.java"/>
      <my-condition some-prop="bar"/>

(the syntax is still evolving, but you get the idea).

Once we get <script-type-def> happening, then it will be even easier to add
new conditions (or any type, for that matter).

> Nor am I entirely sure that a string value of "false" should have any
> special meaning anyway. Are you planning on adding a 'type' attribute for
> <property/> (eg., <property type="boolean" name="flag" value="false"/>)?

Yep, in fact we already do have typed properties.  Properties and references
are one and the same in myrmidon.  You set string properties using the
<property> task:

<property name="some-prop" value="some-value"/>

For non-string properties, you can use either ant 1 style, or the <property>

<path id="my-path">
  <fileset ...>

<property name="my-other-path">
     <fileset ...>

Property values are converted to the appropriate type, as needed.  The
converter is (like everything else) completely pluggable, and you can import
converters from antlibs, or <converter-def> your own custom converters.
This means that you can, for example, override the default convertion for a
particular type, or provide converters that can adapt your custom types to
standard types like, say, path or file.


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

View raw message