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. scohenATSportvisionDOTcom -----Original Message----- From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] 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 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]
