On Friday 14 November 2003 10:53, Stefan Bodewig wrote:
>
> > <presetdef name="my.javac">
> > <javac srcdir="src" destdir="classes"
> > deprecation="${deprecation}" debug="${debug}"/>
> > </presetdef>
>
> I'd expect that the properties have been expanded at the point of
> <presetdef> already so there shouldn't be any shadow affecting that
> definition.
<presetdef> expands the properties at the point of use, not
at the point of definition.
>
> > No here the intention of the code writer was to control javac using
> > the debug property. But just because I decided to write myMacro with
> > an attribute called debug, I am changing the behavior of
> > my.java. (if we use locals)
>
> Only if the expansion of properties in presetdef is performed in the
> scope of the macro invocation and not at definition time. But we
> could simple use your example with
>
> <myMacro debug="true">
> <code>
> <echo>${debug}</echo>
> </code>
> </myMacro>
>
> and ask ourselves what the user wanted to say here. I agree that we
> remove the ambiguity when attributes are not properties.
>
> > But wait, what if I actually wanted to change the property?
> > Well, in that case you can introduce the <local> yourself
> > as part of the code of the macro:
>
> I knew you'd say that (and I even came to this conclusion all by
> myself already ;-).
>
> Peter, Jan, now that we've seen Jose Alberto's use case - what can
> macrodef do when we use (local) properties that can't be done with
> textual substitutions? I may be willing to swallow <local> in 1.6
> even if macrodef attributes don't use it.
I do not like using a different notation for attributes. After
programming in perl for many years, (many years ago), I came to
hate the different notations for arrays, scalars, maps, and ?Files?.
However, if attributes are done by textual notation, they should have
a different notation.
<myMacro debug="true">
<code>
<echo>$(debug) is not ${debug}</echo>
</code>
</myMacro>
Other than that, there is not much differnce. Retaining the ${} format
(implying using local properties) would be a benefit, in that porting
of antcall's would be easier.
If attributes are local properties, there is an issue with shadowing
of user properties. In the above case, it is common for people to
do ant -Ddebug=no ...
>
> The main problems other languages have with macros as textual
> replacements (i.e. Lisp's defmacro or C's #define) is that the
> expression you pass in may be evaluated more than one.
> I.e. #define square(x) x * x and used as square(i++) may lead to
> unexpected results.
>
> The only expression evaluation we have in Ant is property expansion
> and that would have been performed before the value of the attribute
> gets used - and exactly once - no matter how we implement it, wouldn't
> it?
Not quite, the expansion gets performed just before a task is run, and
with macrodef and presetdef, the UE's are stored and (for macrodef's case)
copied. If the expansion is done by macrodef/presetdef, it is difficult to
stop the expansion being done again later. It had a version of
RuntimeConfigureable with kept track of the expansion, but this does not
work for expansion done by tasks for addText().
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
