ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Cohen" <SCo...@sportvision.com>
Subject RE: <macrodef> attributes as properties or as textual substitutions [was <local>]
Date Wed, 05 Nov 2003 17:54:47 GMT
>>Doing this corresponds more closely to current usage of <antcall/> for
templates.

Yes, but I think this may not be such a good thing.  I have, as I
recall, oftentimes been tripped up on the question of when a variable is
defined.  I know java has no preprocessor, but it doesn't have macros
either.  If we are going to introduce macros in ant, I think that the
clarity of knowing that they are defined at load time, and not at
runtime is an advantage.  <antcall>
has never been a good way to do "templates".

Although I might be open to a convincing counter-example.

Steve Cohen
Sr. Software Engineer
Sportvision, Inc. 
scohenATSportvisionDOTcom

-----Original Message-----
From: peter reilly [mailto:peter.reilly@corvil.com] 
Sent: Wednesday, November 05, 2003 11:38 AM
To: Ant Developers List
Subject: Re: <macrodef> attributes as properties or as textual
substitutions [was <local>]


My view is that we should use (local) properties for macrodef
attributes. Doing this corresponds more closely to current usage of
<antcall/> for templates.

If however, one uses textual substitutions, I agree that one should use
a different syntax/notation for the attributes.
     
$(x) may however be too similar to ${x}

As regards <local/>. I think that the local properties should be thread
local. I.e. the following should not cause grief.

<parallel>
   <sequential>
      <local name="x" value="1"/>
      <echo>x is ${x}</echo>
   </sequential>
   <sequential>
      <local name="x" value="2"/>
      <echo>x is ${x}</echo>
   </sequential>
</parallel>

Peter
On Wednesday 05 November 2003 16:30, Jose Alberto Fernandez wrote:
> 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 
> definition. 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 
> should 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 
> multithreading 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 [mailto:bodewig@apache.org]
> > Sent: 03 November 2003 14:08
> > To: dev@ant.apache.org
> > Subject: Re: <macrodef> attributes as properties or as textual 
> > substitutions [was <local>]
> >
> >
> > On Fri, 31 Oct 2003, Antoine Levy-Lambert <antoine@antbuild.com>
> >
> > 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: 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


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message