ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From peter reilly <peter.rei...@corvil.com>
Subject Re: <macrodef> attributes as properties or as textual substitutions [was <local>]
Date Wed, 05 Nov 2003 17:37:33 GMT
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


Mime
View raw message