Return-Path: 
 <dev-return-52650-apmail-ant-dev-archive=ant.apache.org@ant.apache.org>
Delivered-To: apmail-ant-dev-archive@www.apache.org
Received: (qmail 63661 invoked from network); 5 Nov 2003 17:05:31 -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:05:31 -0000
Received: (qmail 20322 invoked by uid 500); 5 Nov 2003 17:05:12 -0000
Delivered-To: apmail-ant-dev-archive@ant.apache.org
Received: (qmail 20263 invoked by uid 500); 5 Nov 2003 17:05:12 -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 20182 invoked from network); 5 Nov 2003 17:05:11 -0000
Received: from unknown (HELO ignitemedia.com) (64.157.167.108)
  by daedalus.apache.org with SMTP; 5 Nov 2003 17:05:11 -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:06:31 -0600
Message-ID: <D466FBEAA19E7E408BE3FAAC6EEB5676038A93E3@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: AcOiE/H7i54DruGUTs6pwic4ux7cXwBmyC7gAAPshyA=
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

This makes a lot of sense to me, especially given your willingness to
consider a different notation (very important, IMHO).  To me, a macro IS
a textual substitution, and anything that leaves things in an undefined
or difficult-to-explain middle state is asking for trouble.  They're
different sorts of beasts and this should not be muddied.

Steve Cohen
Sr. Software Engineer
Sportvision, Inc.=20
scohenATSportvisionDOTcom

-----Original Message-----
From: Jose Alberto Fernandez [mailto:jalberto@cellectivity.com]=20
Sent: Wednesday, November 05, 2003 10:30 AM
To: Ant Developers List
Subject: RE: <macrodef> attributes as properties or as textual
substitutions [was <local>]


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 <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=20
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=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>
>=20
>   <macrodef name=3D"outer">
>     <attribute name=3D"work"/>
>     <attribute name=3D"play"/>
>=20
>     <element name=3D"precompile" optional=3D"true"/>
>     <element name=3D"additional" optional=3D"true"/>
>=20
>     <sequential>
>       <precompile/>
>       <additional/>
>     </sequential>
>   </macrodef>
>=20
>   <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
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=20
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=20
> textual substitutions [was <local>]
>=20
>=20
> On Fri, 31 Oct 2003, Antoine Levy-Lambert <antoine@antbuild.com>
> wrote:
>=20
> > What are the advantages of leaving macrodef with attributes
> > implemented as textual substitutions ?
>=20
> attributes don't hide properties.
>=20
> If we implement attributes as properties, we have to decide
> whether they are allowed to override existing=20
> (user-)properties of the same name as well.  I don't think it=20
> would be problematic, as long as we state the rules clear enough.
>=20
> If they are only textual substitutions, they get confusing
> when we use the property expansion syntax.
>=20
> > 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.
>=20
> I'd rather get this "right" as in community supported and
> unlikely to break bc in Ant 1.7 now.
>=20
> > If we choose a notation $() for macro attributes (for
> instance), can
> > we implement macrodef with <local/> in 1.7 ?
>=20
> You mean we make them textual replacements now and set
> (local) properties in 1.7?  This would imply that attributes=20
> that didn't hide properties in 1.6 would do so now.  And=20
> should we decide that attributes must not override existing=20
> properties, this suddenly would have to apply to $() instead=20
> of ${} as well.
>=20
> Stefan
>=20
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>=20
>=20

---------------------------------------------------------------------
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