Return-Path: 
 <dev-return-52658-apmail-ant-dev-archive=ant.apache.org@ant.apache.org>
Delivered-To: apmail-ant-dev-archive@www.apache.org
Received: (qmail 88241 invoked from network); 5 Nov 2003 17:53:37 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 5 Nov 2003 17:53:37 -0000
Received: (qmail 9279 invoked by uid 500); 5 Nov 2003 17:53:27 -0000
Delivered-To: apmail-ant-dev-archive@ant.apache.org
Received: (qmail 9233 invoked by uid 500); 5 Nov 2003 17:53:27 -0000
Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:dev-unsubscribe@ant.apache.org>
List-Subscribe: <mailto:dev-subscribe@ant.apache.org>
List-Help: <mailto:dev-help@ant.apache.org>
List-Post: <mailto:dev@ant.apache.org>
List-Id: "Ant Developers List" <dev.ant.apache.org>
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Delivered-To: mailing list dev@ant.apache.org
Received: (qmail 9219 invoked from network); 5 Nov 2003 17:53:27 -0000
Received: from unknown (HELO ignitemedia.com) (64.157.167.108)
  by daedalus.apache.org with SMTP; 5 Nov 2003 17:53:27 -0000
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: <macrodef> attributes as properties or as textual substitutions
 [was <local>]
Date: Wed, 5 Nov 2003 11:54:47 -0600
Message-ID: <D466FBEAA19E7E408BE3FAAC6EEB5676050422D5@utah.ignitemedia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: <macrodef> attributes as properties or as textual substitutions
 [was <local>]
thread-index: AcOjw7lWLOUtkek+RhmRUpBXPD6jMgAAWwAA
From: "Steve Cohen" <SCohen@sportvision.com>
To: "Ant Developers List" <dev@ant.apache.org>
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

>>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.=20
scohenATSportvisionDOTcom

-----Original Message-----
From: peter reilly [mailto:peter.reilly@corvil.com]=20
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.
    =20
$(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=3D"x" value=3D"1"/>
      <echo>x is ${x}</echo>
   </sequential>
   <sequential>
      <local name=3D"x" value=3D"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=20
> quite busy at work and haven't had the time.
>
> I would like to give some of my perspective on the issue of=20
> <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=20
> implementation of <atribute>. I am in the camp of <macrodef> doing a=20
> textual expansions (and here I would relent my objections to a=20
> different syntax for attribute variables, in exchange for having=20
> textual replacement done right).
>
> By textual replacement done right, I mean that the scope of the=20
> textual replacement is static on the text of the macro at the time of=20
> definition. That is the replacement should not apply to the value of=20
> attributes or
>
> <elements> passed in the call. So in the famous example:
> >   <macrodef name=3D"inner">
> >     <attribute name=3D"a"/>
> >     <attribute name=3D"b"/>
> >     <sequential>
> >       <echo> name=3D"a" value=3D"$(a)"</echo>
> >       <echo> name=3D"b" value=3D"$(b)"</echo>
> >     </sequential>
> >   </macrodef>
> >
> >   <macrodef name=3D"outer">
> >     <attribute name=3D"work"/>
> >     <attribute name=3D"play"/>
> >
> >     <element name=3D"precompile" optional=3D"true"/>
> >     <element name=3D"additional" optional=3D"true"/>
> >
> >     <sequential>
> >       <precompile/>
> >       <additional/>
> >     </sequential>
> >   </macrodef>
> >
> >   <target name=3D"test.outer">
> >     <outer work=3D"this is work" play=3D"this is play">
> >       <precompile>
> >         <inner a=3D"${work}" b=3D"${play}" />
> >       </precompile>
> >     </outer>
> >   </target>
>
> The output will still be:
> > test.outer:
> >      [echo]  name=3D"a" value=3D"${work}"
> >      [echo]  name=3D"b" value=3D"${play}"
>
> More over, the following call (see usage of attribute notation):
> >   <target name=3D"test.outer">
> >     <outer work=3D"this is work" play=3D"this is play">
> >       <precompile>
> >         <inner a=3D"$(work)" b=3D"$(play)" />
> >       </precompile>
> >     </outer>
> >   </target>
>
> Will also output:
> > test.outer:
> >      [echo]  name=3D"a" value=3D"$(work)"
> >      [echo]  name=3D"b" value=3D"$(play)"
>
> Because the substitutions of $(work)/$(play) attributes MUST occur=20
> before the expansion of <precompile/>.
>
> Why am I so adamant about it? Because I believe a user of a macro=20
> should be isolated from the implementation of the task sa macro. I=20
> should be able to reimplement a <macrodef> as a java <task> and=20
> maintain complete compatibility. This means that macros, like tasks,=20
> 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>=20
> was very similar <param>s of <ant>. They redefine (overide) the value=20
> of a property for a well defined period of time (the <local> nesting)=20
> and after that the property reverts to its original value (state).=20
> Very simple. Since then there has been added functionality for=20
> 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=20
> least possible. Today I think the implementation touches a lot of=20
> 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=20
> > substitutions [was <local>]
> >
> >
> > On Fri, 31 Oct 2003, Antoine Levy-Lambert <antoine@antbuild.com>
> >
> > wrote:
> > > What are the advantages of leaving macrodef with attributes=20
> > > implemented as textual substitutions ?
> >
> > attributes don't hide properties.
> >
> > If we implement attributes as properties, we have to decide whether=20
> > they are allowed to override existing (user-)properties of the same=20
> > name as well.  I don't think it would be problematic, as long as we=20
> > state the rules clear enough.
> >
> > If they are only textual substitutions, they get confusing when we=20
> > use the property expansion syntax.
> >
> > > Otherwise, of course, if we leave macrodef as it is with just a=20
> > > new notation for the attributes, then we can release 1.6 sooner.
> >
> > I'd rather get this "right" as in community supported and unlikely=20
> > 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=20
> > 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