ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher" <>
Subject Re: Immutability
Date Fri, 07 Dec 2001 00:47:36 GMT
----- Original Message -----
From: "Stefan Bodewig" <>
> Has anybody of you (those of you pushing for property immutability in
> the core) had a look at what we decided upon when we put together out
> Ant2 requirements?  I'm talking about
> * make properties fully dynamic, i.e. allow their value to be reassigned

The quote I see is:

"It will be possible to reassign values of properties via a built-in task."

This came from - is this
the definitive reference for Ant2 design?

> Erik, I really appreciate all the work that you have done and you've
> cleanup up a lot of Ant's core classes a fair bit with it, but maybe
> we are really going one or two steps too far?

Oops.... I hope not.  I'm with Jose (yeah, two non-committers causing
trouble! :) on this one as far as the declarative nature of Ant goes.  The
overridability (thats a bad term since its really the first to set wins) is
one of the most powerful and pleasant features of Ant 1.x (1.3+ is my
experience, so not speaking for earlier versions!).

I don't know how its planned to handle allowing properties to change, and
its hard to visualize just design documents even if this is spelled out -
I'd like to see a more concrete example of any kinds of scoping and
overridability and how that would play out in Ant2.

> We want to leave <property> as task the way it is, OK.  We probably
> also want to make all property setting core tasks behave the same way.
> But do we really want to enforce property immutability as a core
> feature?

I think enforcing at the API level is the way to go.  Tasks shouldn't be
allowed to override properties.  I do feel a bit less-strong about things
like <available> and <condition> since I'm really asking "is this file
present?" and if the property is previously set then the answer I get is not
necessarily accurate - but you can see a warning go by and re-using property
names is discouraged, and I can see benefit to being able to override such
things with -D to force something through.

> Our vote in April/May quite clearly says no, and at least
> mine still stands.

I don't read the above quote so strongly.  It says a "built-in" task can
reassign properties - this is currently possible except with a warning.  And
perhaps with some more refactoring a more privileged way of setting
properties could be created and prevent general tasks from doing so at the
API level yet allowing other constructs the capability.

> Having said that, let's rework the last patches so that existing core
> tasks don't override existing properties but there still is an API to
> modify properties.

I think all core tasks except <available> have been reworked to call
setNewProperty.  setProperty still overrides existing properties, except
issues a warning.  The warning could be removed if thats too annoying and we
could just be careful not to use that API call for built-in/optional tasks
(unless desired for some reason).

> Consider this a -1 against the functionality of enforcing property
> immutability in the core.

*ugh*  :)


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message