On Thursday 23 October 2003 12:31, Stefan Bodewig wrote: > On Wed, 22 Oct 2003, peter reilly <[EMAIL PROTECTED]> 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 sequential. > 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. Peter --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
