Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Message-Id: <3.0.6.32.20010116121631.00a79d00@alphalink.com.au>
Date: Tue, 16 Jan 2001 12:16:31 +1100
To: ant-dev@jakarta.apache.org
From: Peter Donald <donaldp@apache.org>
Subject: RE: Ant 2.0 - Frantic: How are properties resolved?
Cc: <ant-dev@jakarta.apache.org>
In-Reply-To: <INEPIJABNNOAONEOKGBFAEMACHAA.jimcook@iname.com>
References: <3.0.6.32.20010116105709.0092db00@alphalink.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 08:08  15/1/01 -0500, James Cook wrote:
>> -----Original Message-----
>> From: Peter Donald [mailto:donaldp@apache.org]
>> Thats what I thought - I am completely and utterly -1 on this aspect.
>> Mainly as it becomes so hard to maintain and requires heaps of extra
>> programming in 90% of the cases. (It is useful in some instances but....)
>> It should be the containers responsibility rather than components. The
>> reason is that moves all complexity to us and leaves task writers with a
>> cake walk ;)
>
>Please elaborate. As far as putting more complexity on us (Ant design), I
>don't see it. In fact, the code that exists now fully supports complex
>property substitution. What is the issue?

What I am saying is that task writers should not have to do a
getProperty()/getAttribute(). All complexity should be on us the engine
writers. So the engine would detect that there is a setFoo() method and
automagically convert the attribute into setFoos() parameter type and then
call setFoo.

>When the program starts, all I have is an object tree. As Tasks get executed
>and nesting levels ensue, I build a property tree that represents the
>runtime structure of the build process. You need two trees because the
>static view (the XML file) does not equal the runtime view. The runtime view
>can jump all over the place in a manner that is not reflected by the task
>hierarchy.

Right - but why do you need to separate the too. Neither of AntEater or
myrmidon separates them - in effect the "runtime" view is throwaway. You
create the object, configure it, execute it and then throw it away. Any
"context" information is past on in variables.

I think we should probably store the execution stack like yours does but I
don't think there is any necessaity to store anything more - or have I
mistaken something ?

Cheers,

Pete

*-----------------------------------------------------*
| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |
*-----------------------------------------------------*