Dominique,
As its name indicates <macrodef/> is a MACRO. And macros are macros are
macros
and they are suppose to be textually replaces at the point on
invocation.
So the fact that properties are substituted at the expansion point is
what anyone understanding that it is a MACRO would expect.
My point with allowing for a way to expand inline, (which I am not even
sure
gives any advantage, since properties are inmutable) is trying to
address
the fact that in many MACRO languages there is some way to evaluate some
things
at definition time and fix the value then. some sort of eval.
Maybe one can acomplish this with some sort of property interceptor: So
a syntax like:
${macroinline:x} will cause the property "x" to be substituted
at definition time
while ${x} will get substituted at expansion time.
> -----Original Message-----
> From: Dominique Devienne [mailto:[EMAIL PROTECTED]
> Sent: 19 August 2003 21:24
> To: 'Ant Developers List'
> Subject: RE: [new tasks] presetdef and macrodef
>
>
> > -----Original Message-----
> > From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, August 19, 2003 12:47 PM
> > To: Ant Developers List
> > Subject: RE: [new tasks] presetdef and macrodef
> >
> > > What I am saying is that even with a different notation for
> > > attributes, normal property resolution will take place in the
> > > context of the user of the macro, and not when the macro
> is defined.
> > > This is a consequence of the way <macrodef/> is implemented, in
> > > particualar to support embedded elements.
> > >
> >
> > Now that you explained this, I would really like to have a way of
> > defining properties that are expanded at definition time. I do not
> > know if it can be done with the syntax we already have or we need
> > something diferent. Probably we do, since we would need a way to
> > distinguish between inlined (replace during definition) and not
> > inlined (replaced during evaluation) properties.
>
> I stopped arguing this point, as I was the only one concerned
> apparently, but since Jose Alberto brings it up again...
>
> Having ${NAME} not evaluate to the value, if any, of the NAME
> property, at the time the task it's used in (<macrodef> is
> this case) is executed, is REALLY REALLY BAD in my sincere
> opinion. Maybe <foreach> does it, but that doesn't make it
> any better. Properties should *always* be evaluated at the
> place where they are defined.
>
> If I'm not mistaken, and ${NAME} is evaluated as the time the
> defined Macro is used, rather than defined, then is becomes
> some kind of implicit attribute of that Macro, and it's much
> better to explicitly define it as an attribute.
>
> OTOH, if it behaves 'normally', as in what Ant does today, it
> is simply a way to customize the way the macro itself (its
> implementation if you will).
>
> It seems that so far, my point has either not been well
> understood, or dismissed (which is troubling to me, given the
> huge confusion that would result IMHO). --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]
