Hi everybody, Hope you don't mind a late join to the discussion.
There is some precedent for this kind of thing in Ant -- extension-points. In fact, extension-points plus appendable paths / filesets is a potent combination. You know: * base script declares a few standard, empty data structures -- paths, filesets, extension-points * layered scripts declare contributions to each of these data structures -- add build directories to the downstream classpath, compile targets to the "build" extension-point, etc append/prepend isn't as far a departure from the current model as would be allowing complex expressions or arbitrary transformations. -jason On Fri, Mar 26, 2010 at 1:29 AM, Gilles Scokart <gscok...@gmail.com> wrote: > 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 <br...@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<anto...@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-unsubscr...@ant.apache.org > > For additional commands, e-mail: dev-h...@ant.apache.org > > > > >
