ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <DDevie...@lgc.com>
Subject RE: [new tasks] presetdef and macrodef
Date Wed, 20 Aug 2003 13:53:53 GMT
Well, I must be stupid then... Unlike you, I don't consider <macrodef> a
MACRO at all. It has nothing to do with *textual* replacement. The
non-existent <include>, and XML entity includes *are* textual replacement.
<macrodef> certainly is NOT. <macrodef> is a TASK, which happens to define
and the same time it implement a(nother) new TASK, using Ant's native XML
syntax rather than Java code. It could as much be called <taskimpl>, and the
feeble link to MACRO would then be even more tenuous that it already is!

It turns out that when you write the implementation of that new task, you
*ARE* using Ant's syntax to 'code' it, and thus Ant normal behavior of
expanding properties *AS USUAL* should be respected.

It's a huge leap to say the least to consider <macrodef> defining a textual
MACRO. I myself am very aware of Ant's introspection and property expansion
rules, which is why I *expect* them to be applied everywhere in Ant.

So I repeat: I'm -1 to <macrodef> with non-standard expansion of Ant
properties. This is non-bidding of course, as I am not a committer... --DD

> -----Original Message-----
> From: Jose Alberto Fernandez [mailto:jalberto@cellectivity.com]
> Sent: Wednesday, August 20, 2003 7:34 AM
> To: Ant Developers List
> Subject: RE: [new tasks] presetdef and macrodef
> 
> 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:DDevienne@lgc.com]
> > Sent: 19 August 2003 21:24
> > To: 'Ant Developers List'
> > Subject: RE: [new tasks] presetdef and macrodef
> >
> >
> > > -----Original Message-----
> > > From: Jose Alberto Fernandez [mailto:jalberto@cellectivity.com]
> > > 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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message