ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Scokart <>
Subject Re: task that allows augmentation of previously declared references
Date Fri, 26 Mar 2010 08:29:43 GMT
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 <> 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<>  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:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message