>>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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] > > Sent: 03 November 2003 14:08 > > To: [EMAIL PROTECTED] > > Subject: Re: <macrodef> attributes as properties or as textual > > substitutions [was <local>] > > > > > > On Fri, 31 Oct 2003, Antoine Levy-Lambert <[EMAIL PROTECTED]> > > > > 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
