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:[EMAIL PROTECTED] > 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:[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]
