> From: peter reilly [mailto:[EMAIL PROTECTED] 
> 
> On Monday 20 October 2003 13:25, Jose Alberto Fernandez wrote:
> >
> > So what do I get on the ant/antcall/subant side of things?
> > Do I get the original global value? Or nothing?
> 
> The original global value.
> 

I think I have misgivings about this. I may understand assumming
the local as undefined in the call (not inherited), but skiping it and
passing
an old value from the stack, sounds to say the least very confusing
if not wrong. 

The worst part is that there is no way for me to know what is the value
being passed. In the following fragment:

  <macrodef name="m">
    <local name="a" value="A">
      <antcall target="w"/>
    </local>
  </macrodef>

  <target name="x">
    <local name="a">
      <m/>
    </local>
  </target>

There is no way for me to know what would be the value of "a" in the
antcall. There is no
way to know what the <antcall> is actually sending, because the variable
is hidden
behind two levels of local. Which means it is more difficult to
encapsulate code.

Jose Alberto

> > If I need to pass this value, does that mean I need to use <param> 
> > explicitly?
> 
> Yes, one would need to use <param/> explicity
> 
> > This would have to be documented very well
> > because it may be confusing otherwise.
> 
> Indeed..
> >
> > I understand your selection in the context of the attributes of 
> > <macrodef> but I was thinking on the general case. So let 
> at least add
> > a strong usage description in the docs for <local>.
> 
> Another reason is that I wanted the local properties to be 
> staticly scoped. However in the implementation this is not 
> really the case in that tasks have access to the properties - 
> see the script example.
> 
> Yet another reason is that the Ant.java does a *lot* of 
> messing with properties. It is quite possible any 
> modificiation would cause problems to current scripts.
> 
> Peter
> 
> >
> > Jose Alberto
> > PS: BTW I think this is one of the best features we have 
> added to ANT 
> > so I hope it manages to get to 1.6. With this feature alone one can 
> > get rid of all those anoying properties whose only reason for 
> > existance was passing a value between two tasks.
> >
> > > Peter
> > >
> > > > Jose Alberto
> >
> > 
> ---------------------------------------------------------------------
> > 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]
> 
> 

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

Reply via email to