Return-Path: 
 <dev-return-52257-apmail-ant-dev-archive=ant.apache.org@ant.apache.org>
Delivered-To: apmail-ant-dev-archive@www.apache.org
Received: (qmail 40528 invoked from network); 23 Oct 2003 11:55:27 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 23 Oct 2003 11:55:27 -0000
Received: (qmail 25856 invoked by uid 500); 23 Oct 2003 11:55:24 -0000
Delivered-To: apmail-ant-dev-archive@ant.apache.org
Received: (qmail 25592 invoked by uid 500); 23 Oct 2003 11:55:22 -0000
Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:dev-unsubscribe@ant.apache.org>
List-Subscribe: <mailto:dev-subscribe@ant.apache.org>
List-Help: <mailto:dev-help@ant.apache.org>
List-Post: <mailto:dev@ant.apache.org>
List-Id: "Ant Developers List" <dev.ant.apache.org>
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Delivered-To: mailing list dev@ant.apache.org
Received: (qmail 25575 invoked from network); 23 Oct 2003 11:55:21 -0000
Received: from unknown (HELO corvil.com) (213.94.219.177)
  by daedalus.apache.org with SMTP; 23 Oct 2003 11:55:21 -0000
Received: from preilly.local.corvil.com (preilly.local.corvil.com
 [172.18.1.173])
	by corvil.com (8.12.9/8.12.5) with ESMTP id h9NBtKd8076046
	for <dev@ant.apache.org>; Thu, 23 Oct 2003 12:55:20 +0100 (IST)
	(envelope-from peter.reilly@corvil.com)
From: peter reilly <peter.reilly@corvil.com>
Organization: corvil
To: Ant Developers List <dev@ant.apache.org>
Subject: Re: Vote: <local> for 1.6
Date: Thu, 23 Oct 2003 12:55:38 +0100
User-Agent: KMail/1.5
References: <200310211635.48228.peter.reilly@corvil.com>
 <200310221835.46607.peter.reilly@corvil.com> <m3smlknqb4.fsf@bodewig.bost.de>
In-Reply-To: <m3smlknqb4.fsf@bodewig.bost.de>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200310231255.38192.peter.reilly@corvil.com>
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

On Thursday 23 October 2003 12:31, Stefan Bodewig wrote:
> On Wed, 22 Oct 2003, peter reilly <peter.reilly@corvil.com> 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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org