> From: Dominique Devienne [mailto:[EMAIL PROTECTED]
>
>
> > From: peter reilly [mailto:[EMAIL PROTECTED]
> >
> > It appears that the attributes as local properties
> > patch
> >
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=23942
> >
> > causes macrodef to behave in the way you expect.
> >
> > A cut-down version shows this.
> >
> > <project>
>
> Let me add:
>
> <property name="a" value="AAA" />
> <property name="b" value="BBB" />
>
I think a more compelling argument for variable hiding is what would
happen
if one have instead:
<property name="work" value="AAA" />
<property name="play" value="BBB" />
with this properties, there is no way on earth that one can justfy why
the
following two lines are not equivalent in the expansion of the target:
<inner a="${work}" b="${play}" />
<inner a="AAA" b="BBB" />
> > <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>
> > </project>
> >
> >
> > Ant 1.6 currently outputs:
> > test.outer:
> > [echo] name="a" value="${work}"
> > [echo] name="b" value="${play}"
> >
> > With the patch
> > this gets output:
> >
> > test.outer:
> > [echo] name="a" value="this is work"
> > [echo] name="b" value="this is play"
> >
> > Peter
>
> What's the output now, with the addition?
>
> I assume currently property 'a' and 'b' are simply ignored
> and the output you show above Peter doesn't change w/ or
> w/out the patch. This behavior has a name, and it's *variable
> hiding* (properties here in fact), and it's not a recommended
> behavior.
>
> As a user of Ant pre-<macrodef>, I would expect the output to
> be (with my
> addition):
>
> test.outer:
> [echo] name="a" value="AAA"
> [echo] name="b" value="BBB"
>
> And without it:
> [echo] name="a" value="${a}"
> [echo] name="b" value="${b}"
>
> Of course, one would then need a new notation to de-reference
> the attributes of the <macrodef>... Exactly what was rejected
> in the first place.
>
> Adding this new notation for <macrodef> attributes
> disambiguates regular property de-references, from the
> macro's attributes, once and for all.
>
As we have gone on this discussion before, I do not think in your
example we are doing actual bad variable hidding. What we are doing
is applying static scoping rules for attributes. That is, a local
variable (attribute) is hidding access (statically) to a global
variable (property). This is what we do on every structured prog.
language.
That is, "a" and "b" change meaning only inside the static context
of the macro.
In my variant, the variable hidding occurs outside the context of the
macrodef
that is I am doing an expansion of a property on a target and somehow
I get the value defined in a macrodef that may not even know what it
does
(it could have come in an antlib, or an import).
Jose Alberto
> As far as using the local patch, yes, it does make sense as
> you show above, but it still doesn't solve the point I've
> been trying to make from the get go, and that apparently
> everybody else simply dismisses. --dD
>
> ---------------------------------------------------------------------
> 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]
