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 )
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).
It seems to me that the natural thing to do is to separate
the two. Leaving the former just to be able to define
local scopes, and for the later having a new datatype
(Reference object) for defining ThreadLocal objects.
For completeness, this would probably mean also allowing
<local> to scope references, so that they do not become
some sort of second class citizen.
So here is what I am putting on the table:
Reset property for local scope
<local property="a">
...
</local>
Redefine property for local scope
<local property="a" value="A">
...
</local>
Define reference for local scope
<local refid="bID">
...
</local>
ThreadLocals would be defined using a diferent typedef
something like:
<thread-local id="my-local" string="XXX"/>
As a reference the value can be changed without any problem,
and you can obtain its string value by doing ${toString:my-local}.
(it is a feature of the 1.6 code).
Hummmmm, maybe wa could allow:
<thread-local id="my-local">
<fileset ... />
</thread-local>
Which means any datatype could be made thread-local.
Well food for thought,
Jose Alberto
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
