ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: <macrodef> attributes as properties or as textual substitutions [was <local>]
Date Wed, 05 Nov 2003 16:30:24 GMT
Sorry to have taken so long for me to answer this message but I am 
quite busy at work and haven't had the time.

I would like to give some of my perspective on the issue of
<macrodef/> and <local/>.

My first comment is that I really believe these two features should
be kept apart. I do not think <macrodef/> should use <local>
in the implementation of <atribute>. I am in the camp of <macrodef>
doing a textual expansions (and here I would relent my objections to 
a different syntax for attribute variables, in exchange for having
textual replacement done right).

By textual replacement done right, I mean that the scope of the textual
replacement is static on the text of the macro at the time of
That is the replacement should not apply to the value of attributes or
<elements> passed in the call. So in the famous example:

>   <macrodef name="inner">
>     <attribute name="a"/>
>     <attribute name="b"/>
>     <sequential>
>       <echo> name="a" value="$(a)"</echo>
>       <echo> name="b" value="$(b)"</echo>
>     </sequential>
>   </macrodef>
>   <macrodef name="outer">
>     <attribute name="work"/>
>     <attribute name="play"/>
>     <element name="precompile" optional="true"/>
>     <element name="additional" optional="true"/>
>     <sequential>
>       <precompile/>
>       <additional/>
>     </sequential>
>   </macrodef>
>   <target name="test.outer">
>     <outer work="this is work" play="this is play">
>       <precompile>
>         <inner a="${work}" b="${play}" />
>       </precompile>
>     </outer>
>   </target>

The output will still be:

> test.outer:
>      [echo]  name="a" value="${work}"
>      [echo]  name="b" value="${play}"

More over, the following call (see usage of attribute notation):

>   <target name="test.outer">
>     <outer work="this is work" play="this is play">
>       <precompile>
>         <inner a="$(work)" b="$(play)" />
>       </precompile>
>     </outer>
>   </target>

Will also output:

> test.outer:
>      [echo]  name="a" value="$(work)"
>      [echo]  name="b" value="$(play)"

Because the substitutions of $(work)/$(play) attributes MUST occur
before the expansion of <precompile/>.

Why am I so adamant about it? Because I believe a user of a macro
should be isolated from the implementation of the task sa macro. I
be able to reimplement a <macrodef> as a java <task> and maintain
complete compatibility. This means that macros, like tasks, must
set properties or references to pass information between them.
I shouldn't be able to do with a macro something that cannot be done
cleanly with a <task>.

Now, with respect to <local>. The way I originally envisioned <local>
was very similar <param>s of <ant>. They redefine (overide) the value
of a property for a well defined period of time (the <local> nesting)
and after that the property reverts to its original value (state).
Very simple. Since then there has been added functionality for
which I think has made <local> a little too complex for my taste.

I think we should try to simplify this feature so it touches core the 
least possible. Today I think the implementation touches a lot of places
of core, that should be reduced to just a few (making <local> a subtask
of <sequential> would help on some of that simplification).

Will stop here now I here your comments,

Jose Alberto

> -----Original Message-----
> From: Stefan Bodewig [] 
> Sent: 03 November 2003 14:08
> To:
> Subject: Re: <macrodef> attributes as properties or as 
> textual substitutions [was <local>]
> On Fri, 31 Oct 2003, Antoine Levy-Lambert <>
> wrote:
> > What are the advantages of leaving macrodef with attributes 
> > implemented as textual substitutions ?
> attributes don't hide properties.
> If we implement attributes as properties, we have to decide 
> whether they are allowed to override existing 
> (user-)properties of the same name as well.  I don't think it 
> would be problematic, as long as we state the rules clear enough.
> If they are only textual substitutions, they get confusing 
> when we use the property expansion syntax.
> > Otherwise, of course, if we leave macrodef as it is with just a new 
> > notation for the attributes, then we can release 1.6 sooner.
> I'd rather get this "right" as in community supported and 
> unlikely to break bc in Ant 1.7 now.
> > If we choose a notation $() for macro attributes (for 
> instance), can 
> > we implement macrodef with <local/> in 1.7 ?
> You mean we make them textual replacements now and set 
> (local) properties in 1.7?  This would imply that attributes 
> that didn't hide properties in 1.6 would do so now.  And 
> should we decide that attributes must not override existing 
> properties, this suddenly would have to apply to $() instead 
> of ${} as well.
> Stefan
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message