Ok, here are my responses:
> From: Dominique Devienne [mailto:[EMAIL PROTECTED]
>
>
> I haven't looked at your impl Peter, but there are two things
> about Jose Alberto's proposal I wanted to note:
>
> 1) The generated unique name would need to at least use the
> 'let' name's as a prefix, otherwise the verbose/debug output
> of Ant will be difficult to use when troubleshooting.
>
Actually all this properties are of the form:
prefix#org.apache.tools...LetAttribute#number
where 'prefix' is optional and can be specified in the <let>.
The idea of the prefix, is that one can use this in conjunction with
<propertyset/> to avoid propagating temp properties through <ant*>
calls.
> 2) All these uniquely named properties go on living after
> the macro has executed. That pollutes the namespace.
>
Yes it does. But I still have to see a good argument on why shall
that bother anyone. Unless you are talking about millions of executions
within one project context. You can always mitigate this in
some very complex build by using <antcall/> as a way fence out
chuncks of temporary properties. But I would like to see a good
example in whch this pollution is a real problem.
> I'd prefer a solution that (1) doesn't leak out any temporary
> property once the macro is done executing, and (2) that uses
> the simpler and macro-specific @{name} notation.
>
I really do not see how this is possible as @{...} are macro
substitutions that do not have a life of its own. I.e., there
is no way to test about the existance of @{...} as they either
are defined or are a syntax error. What I proposed it seems
is closer to that. You can say:
<macrodef...>
<let name="foo"/>
...
<isset property="@{foo}" />
...
<property name="@{foo}" value="bar"/>
<echo>[EMAIL PROTECTED]</echo>
...
Yes we could invent yet another syntax shortcut for [EMAIL PROTECTED]
but do you remember how long a fight it took to gt to the current
notation for macrodef attributes. I would prefer avoiding it.
In any case the notation I am using is already there and it is
the only one available for regular attributes. Why do we need a
different one?
> If Peter's patch does this, then I'd prefer his. Thanks, --DD
My worries with these other solutions are that they not only touch
macrodef and propertyHelper, they modify target, ant, sequential,
parallel,and several other
tasks. So what about 3rd party defined tasks. How they will be affected
by such a deep change? What changes would be required for people that
have implemented their own
TaskContainers? Would it just work or are there hidden issues?
This is why I feel a little reluctant to such a deep change just to
support ${...} notation.
Jose Alberto
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
