> -----Original Message-----
> From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
> Sent: Thursday, August 21, 2003 5:56 AM
> To: Ant Developers List
> Subject: RE: [new tasks] presetdef and macrodef
>
> I have no big issue on which syntax is used on each case, but I just
> would like to point out that there are actually 3 types of properties that
> need to be taken into consideration:
>
> 1) Properties to be expanded when the definition of the macro is found
> This is what Dominique wants "${xyz}" to mean, and I was looking for
> a syntax to express it.
That's the way properties have worked, and it should stay that way!
> 2) Attribute properties which are parameters on the call of the macro
> This is what people want to have a different syntax for, to
> distinguish from the rest, it was proposed to use [EMAIL PROTECTED] or
> (@xyz).
Thus the single new syntax (@attr-name) for example.
> 3) Properties to be expanded at the time of the call from the
> environment in which the call is made, this is what "${xyz}"
> means right now. As a macro or template definition I need to
> have a way to refer to things in the context of the expansion,
> so we need syntax for it.
There is absolutely no need for this 'implicit' attribute!!!
If you want your macro to be parametrizeable on something,
define an additional attribute.
You can then use the regular ${name} syntax to populate that explicit
attribute value, which regular ${name} semantic.
> So as you can see there are three diferent things here, that need to be
> represented. I really do not like inventing three diferent notations,
> if it can be helped in particular given the fact that we already have
> a ton of machinery in ANT that has been defined and seem to never
> being reused.
Uhh? Unused machinery? Anyways...
These is not 3 different things. There regular property expansion as it has
always been, and there a new syntax for dealing with a new type of tasks (or
meta-tasks I should say) like <macrodef>, and <foreach> if it ever makes it
to Ant.
I never said <macrodef> is bad, on the contrary. What I have been saying all
along, and will persist on saying, is that the meaning ${name} should *NOT*
be overloaded in any way, and the way to do this is to introduce a new
syntax for attributes/variables for tasks like <macrodef> and <foreach>.
And I'll persist with my -1 on <macrodef> as long as it overloads the
meaning of ${name}. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
