Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
From: "Conor MacNeill" <conor@m64.com>
To: <ant-dev@jakarta.apache.org>
Subject: RE: Why Properties became immutable
Date: Mon, 24 Jul 2000 01:28:29 +1000
Message-ID: <005d01bff4ba$a724e290$80dc1fcb@cognet.com.au>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-reply-to: <m3g0p3c3ts.fsf@sbodewig.bost.de>
Importance: Normal

Stefan,

> From: Stefan Bodewig [mailto:bodewig@bost.de]

I've been away for the weekend but there seems to have been a lot of heat
about this issue. I'm still going through all the ant mails ...

Anyway, I think you have well explained why properties became immutable, but
I think it would be good to look at the spec document again ...

> Properties

> Properties are mutable name-value pairs that are scoped to the
> Project and held in a table. Only one pair is allowed per name.
> It is anticipated that this data structure would be of type
> java.util.Properties or a type that has approximatly the same
> contract.

I don't know if the intention here is parse-time mutability or execute-time
mutability. After all, when you say in the subject of this email that
properties are immutable, you really mean immutable during the parsing and
${} replacement stage. Properties are still mutable by tasks.

> Properties can be defined in a hierarchical manner. The order of
> precidence in this hiearchy is:

> Properties defined on the command line or via a GUI tool
> Properties defined in the text file which defines the project.
> Properties defined in a file in the users user.home directory
> Properties defined in the installation directory that can be
> shared by multiple users.

I think immutability has been introduced primarily to support this
hierarchy. Perhaps we should introduce parse-time mutability within the same
level of the hierarchy. If a higher precedence value is available, it would
be used regardless of what values and transformations are applied at a lower
precedence level. If a higher precedence value is not available, then the
transformations will be allowable.

> Note: The current version of Ant allows the System property
> list to be consulted for a return value if the property list
> doesn't satisfy the requested property name. As all Java code
> has access to the system property list via the java.lang.System
> class, this functionality is considered to be confusing and
> to be removed.

Well, I don't understand that bit and I have seen something in another
thread about it. I think that should go from the spec, or perhaps Duncan can
share his vision?

> Note: The current version of Ant allows property substitution
> to be performed in the project file. This functionality is
> being removed.

That too - what does it mean?

Also, as we know the ${} syntax is being considered for replacement. The
longer it lives, the less popular will be its removal. If we are to remove
it, I'd like to see what people would consider a better alternative (lifting
the lid on Pandora's box??)

On the point you raised in your email, I think properties should have
project-scope only and not target scope. Target scope implies a
functionality which is not there.

Finally, it seems that this change is driving people in all different
directions to sub-projects, XSL, IMake and who knows what else. Two-step
builds using files made by experts, with a whole lot of additional
processing, seem to me to endanger ant's design goals - simplicity and
understandability.

Conor