Hi,
I understand that there is a consensus to have macrodef use @{attribute}
notation.
I am not afraid that we cannot get committers support for local, I am more
afraid that in the course of introducing local, there will be more
discussions concerning issues of scope, thread support, ..., which will
further delay the release of 1.6.
My preference would be to turn macrodef to use @{attribute} for 1.6 and
delay local for 1.7.
Peter, how soon can you deliver the @{attribute} change ?
I would like the following scenario :
- introduce @{attribute} in 1.6 and in HEAD,
- fix failing testcases
- deliver a beta3
- introduce local in HEAD
- deliver ant 1.6
Cheers,
Antoine
-----Ursprungliche Nachricht-----
Von: Stefan Bodewig [mailto:[EMAIL PROTECTED]
Gesendet: Dienstag, 2. Dezember 2003 16:20
An: [EMAIL PROTECTED]
Betreff: Re: Ant 1.6 local and ThreadLocals
On Mon, 1 Dec 2003, Jose Alberto Fernandez <[EMAIL PROTECTED]>
wrote:
> Well now that we are finally getting to an agreement
> on <macrodef> I think it is time to start a new round
> of rocous over <local>, (not enough traffic today ;-P )
We don't seem to be too successful in generating responses these
days. 8-)
I'm a bit torn between releasing 1.6 without any local support and
trying to get enough support for it to delay 1.6 further. I think
local is necessary to make macrodef as powerful as it should be, but
wouldn't want to wait another two months to finally get committer
support for it into 1.6.
> I still fill a little unconfortable on using <local>
> for defining local-scopes (which was the original usage)
> and using <local> to define values that must be different
> on different threads of execution (i.e., Java ThreadLocals).
Hmm,
<parallel>
<sequential>
<local property="a">
...
</local>
</sequential>
<sequential>
<local property="a">
...
</local>
</sequential>
</parallel>
should give something predictable - or something that is completely
undefined, much like what we'd currently have for references.
The above looks like a "user's fault" situation, until you let
<macrodef>'s using <local>s into the game.
<macrodef name="foo">
<sequential>
<local name="my-temporary-variable">
...
</local>
</sequential>
</macrodef>
with multiple invocations of <name> inside <parallel>. For a scenario
like this, <local> implicitly promises to be Thread local. At least
it does for me.
Stefan
---------------------------------------------------------------------
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]
