Return-Path: 
 <dev-return-52641-apmail-ant-dev-archive=ant.apache.org@ant.apache.org>
Delivered-To: apmail-ant-dev-archive@www.apache.org
Received: (qmail 42804 invoked from network); 5 Nov 2003 16:31:12 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 5 Nov 2003 16:31:12 -0000
Received: (qmail 38596 invoked by uid 500); 5 Nov 2003 16:30:24 -0000
Delivered-To: apmail-ant-dev-archive@ant.apache.org
Received: (qmail 38554 invoked by uid 500); 5 Nov 2003 16:30:24 -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 38462 invoked from network); 5 Nov 2003 16:30:23 -0000
Received: from unknown (HELO london.cellectivity.com) (212.18.242.163)
  by daedalus.apache.org with SMTP; 5 Nov 2003 16:30:23 -0000
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: <macrodef> attributes as properties or as textual substitutions
 [was <local>]
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MIMEOLE: Produced By Microsoft Exchange V6.0.5762.3
Date: Wed, 5 Nov 2003 16:30:24 -0000
Message-ID: <747F247264ECE34CA60E323FEF0CCC0C0F5153@london.cellectivity.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: <macrodef> attributes as properties or as textual substitutions
 [was <local>]
thread-index: AcOiE/H7i54DruGUTs6pwic4ux7cXwBmyC7g
From: "Jose Alberto Fernandez" <jalberto@cellectivity.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

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]=20
> 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=20
> > implemented as textual substitutions ?
>=20
> attributes don't hide properties.
>=20
> If we implement attributes as properties, we have to decide=20
> 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=20
> when we use the property expansion syntax.
>=20
> > Otherwise, of course, if we leave macrodef as it is with just a new=20
> > notation for the attributes, then we can release 1.6 sooner.
>=20
> I'd rather get this "right" as in community supported and=20
> unlikely to break bc in Ant 1.7 now.
>=20
> > If we choose a notation $() for macro attributes (for=20
> instance), can=20
> > we implement macrodef with <local/> in 1.7 ?
>=20
> You mean we make them textual replacements now and set=20
> (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