Return-Path: 
 <ant-dev-return-20348-qmlist-jakarta-archive-ant-dev=jakarta.apache.org@jakarta.apache.org>
Delivered-To: apmail-jakarta-ant-dev-archive@apache.org
Received: (qmail 13909 invoked from network); 27 Nov 2001 21:24:06 -0000
Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131)
  by daedalus.apache.org with SMTP; 27 Nov 2001 21:24:06 -0000
Received: (qmail 14607 invoked by uid 97); 27 Nov 2001 21:24:06 -0000
Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org
Received: (qmail 14577 invoked by uid 97); 27 Nov 2001 21:24:05 -0000
Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
List-Unsubscribe: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
List-Subscribe: <mailto:ant-dev-subscribe@jakarta.apache.org>
List-Help: <mailto:ant-dev-help@jakarta.apache.org>
List-Post: <mailto:ant-dev@jakarta.apache.org>
List-Id: "Ant Developers List" <ant-dev.jakarta.apache.org>
Reply-To: "Ant Developers List" <ant-dev@jakarta.apache.org>
Delivered-To: mailing list ant-dev@jakarta.apache.org
Received: (qmail 14543 invoked from network); 27 Nov 2001 21:24:04 -0000
Message-Id: <5.1.0.14.0.20011127131316.00a921b8@orson.callenish.com>
Date: Tue, 27 Nov 2001 13:23:57 -0800
To: "Ant Developers List" <ant-dev@jakarta.apache.org>
From: Bruce Atherton <bruce@callenish.com>
Subject: Re: <available> / <condition> breaking immutability
In-Reply-To: <001d01c1777e$0246e5f0$0100a8c0@jose>
References: <5.1.0.14.0.20011127101723.040e2c68@orson.callenish.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

At 07:59 PM 11/27/2001 +0000, Jose Alberto Fernandez wrote:

>I do not think why it needs to be more complex to use. I think we can find a
>solution to the issue by providing a simpler alternative to the <format> 
>subelement
>which I would agree it is a little too much.

Thanks for that. Your solution would indeed be fine in this case.

What I am really arguing, though, is that there are good reasons to allow 
the system to produce values that change. <tstamp> is one example, but as 
Ant progresses there will be others.

I just see this as a design being driven by semantics because the word 
"property" is referring to two different things in Ant, and I think the 
complexity forced on the user by not separating them is a bad thing.

Imagine Ant had no properties. Instead, users can create "dogs" with the 
<dog> tag (pun intended). The system is able to create "cats". A "mammal" 
(either a dog or a cat) can be expanded with ${name}. Dogs are immutable. 
Only tasks can affect cats, and only if it is clearly the right thing to do 
to accomplish their task. All tasks clearly document what they do to cats.



--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>