ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From peter reilly <>
Subject Re: Vote: <local> for 1.6
Date Thu, 23 Oct 2003 11:55:38 GMT
On Thursday 23 October 2003 12:31, Stefan Bodewig wrote:
> On Wed, 22 Oct 2003, peter reilly <> wrote:
> > On Wednesday 22 October 2003 15:04, Stefan Bodewig wrote:
> >> What is the benefit of making <property> adhere to the scoping set
> >> up by <local>?
> >
> > The point is that all tasks including <property> see the local
> > properties as normal properties.
> So it is supposed to behave like all other property setting tasks, I
> understand.
> Currently I tend to agree with Jose Alberto that using a <local>
> container would be more intuitive.

See my lastest e-mail, I do not think a <local> container is necessary,
as it needs to hold multiple local's winding up looking like

> Your approach gets very confusing if you add dynamic extent to it,
> i.e. if you make <*ant*> inherit local values (as you say yourself).
> So I agree with you that <local> - if implemented the way you have
> implemented it - should be lexically scoped much like a local variable
> in a method.  I wouldn't want to hunt several levels of build files to
> find whether one <local> has been shadowing my global value.

Yep, I think that local should be staticly scoped as far as possible.

> I haven't checked, but does you current implementation allow <local>
> to shadow use properties?  IMHO it shouldn't.

It does shadow user properties. The reason is to support <macrodef>
attributes. It would be confusing if a macrodef attribute
were overridden by a user -Dx=y command line.

However, I could change the implemenation so that <local> did not shadow
user properties, and macrodef attributes did.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message