Mailing-List: contact dev-help@ant.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <dev@ant.apache.org>
Received-SPF: pass (athena.apache.org: domain of gscokart@gmail.com designates
 209.85.218.213 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type;
        b=clXSBcr03pDzQ598udxk5bPDnAWWO/WROGoBpVSroTyb/4vtejB2fU9BDxwErJZSZj
         9RqpowFk9zaZrvzbEQor2JihcBY4HSD8g9vkzpKNzkGj1YfxaNa7UbuVa6LfMp4pFIkV
         hRYPLeFSrtVE+BlC9FFrkr5g9TgZMn39/vdQc=
MIME-Version: 1.0
In-Reply-To: <4BABEA7C.3050703@callenish.com>
References: <4EEC2385-E3B8-4642-9A62-D786632E21AB@gmail.com>
	 <e9d8a2611002250800y32e788beu328cfda09551a8d@mail.gmail.com>
	 <255d8d691002250853r763fe532xdbb0b704bc9cc9fb@mail.gmail.com>
	 <e802d55e1003220342l15750510p403a24b78b8523e5@mail.gmail.com>
	 <0D2CCB35-1A75-4AB6-B51B-820BD52DF829@gmail.com>
	 <87hbo7pr9g.fsf@v35516.1blu.de> <4BA91D74.6020908@gmx.de>
	 <87d3ysfk06.fsf@v35516.1blu.de> <4BABEA7C.3050703@callenish.com>
Date: Fri, 26 Mar 2010 09:29:43 +0100
Message-ID: <e9d8a2611003260129g290bea39y5dff2c2a0f7a6e38@mail.gmail.com>
Subject: Re: task that allows augmentation of previously declared references
From: Gilles Scokart <gscokart@gmail.com>
To: Ant Developers List <dev@ant.apache.org>
Content-Type: multipart/alternative; boundary=0003255577562183890482aff7a0

--0003255577562183890482aff7a0
Content-Type: text/plain; charset=ISO-8859-1

I agree with your argumentation about final in java.  But I'm not sure you
can translate that to ant.

First, I have access to the overwrite method in 1 key in my java IDE.  In
ant, it might be a little bit more complex.

Secondly, I continue to see ant as a declarative language (although inside
the target, the ant tasks follow an imperative style).   And in a
declarative language, it is much more unusual to overwrite/modify the
declaration.  Immutability has great value in declarative language.


Gilles Scokart


On 25 March 2010 23:58, Bruce Atherton <bruce@callenish.com> wrote:

> I agree. I see that the intent in such a final attribute is to keep a build
> system understandable at a local level without worrying about what external
> entities might do, but if you feel that way don't use augmentation in your
> build system. The only reasons I use final keyword in programming are
> security and performance, neither of which apply here. It is too hard to
> predict where extensibility can prove useful to pre-empt it beforehand.
>
> I've tried to figure out a usecase for a final attribute, and the only one
> I can think of is if you have a bunch of generic build files with the same
> target names called from a master build file, and in some instances you want
> the target augmented from the master build file and in some you don't. That
> doesn't sound like it is very compelling for adding the attribute on the
> first pass of the augment feature.
>
>
> On 25/03/2010 9:23 AM, Stefan Bodewig wrote:
>
>> On 2010-03-23, Antoine Levy Lambert<antoine@gmx.de>  wrote:
>>
>>
>>
>>> I prefer not to place any restriction on the<augment/>  feature .
>>> In fact references currently can be modified by user developed ant
>>> tasks or script fragments.
>>>
>>>
>> So you say since references can be overridden without augment it doesn't
>> make any sense to restrict augment?  Sounds reasonable.
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>

--0003255577562183890482aff7a0--