> From: Peter Reilly [mailto:[EMAIL PROTECTED] 
> 
> Stefan Bodewig wrote:
> 
> >Nicer?  Maybe.  I still think a special task container would 
> be cleaner 
> >since it provided explicit scoping and might even help us 
> route around 
> >the "custom PropertyHelpers problem".  Something like
> >
> ><target name="example">
> >  <let>
> >    <local name="prop" value="a local value"/>
> >    <echo>prop is ${prop}</echo>
> >  </let>
> ></target>
> >
> >  
> >
> Ok, I am modifying the local patch to do:
> 
> <target name="example">
>   <let>
>     <localproperty name="prop" value="a local value"/>
>     <echo>prop is ${prop}</echo>
>   </let>
> </target>
> 
> 
> So, Task, Target, Parallel do not get changed.
> 
> I also think that the nested localproperty for the macrodef 
> task can be 
> dropped
> initially. It would be easier to explain just one container for local 
> properties/
> 

Peter, 

The original reason for all the threadlocal stuff was to allow writing
things like:

    <parallel>
      <macro1 agr="1"/>
      <macro1 arg="2"/>
    </parallel>

Where "macro1" defines locals and in that case we do not want the
different threads to interfere with each other. Now does your changes
deal with this issue?

The whole point of my comments is that we cannot just take a blanket
policy
this way or that because it depends on the intensions of the user.
This is why I just provide new names, because our main problem is name
clashing
as we have a single flat namespace i.e., global-variables. 
And there is lots of code relying on this fact.

Jose Alberto

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to