ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject RE: Did somebody say Shut up and Write? :)
Date Wed, 20 Dec 2000 06:06:07 GMT
At 12:54  20/12/00 -0500, James Cook wrote:
>> -----Original Message-----
>> Would you advocate the same thing in our case - ie we throw an
>> exception if
>> develoeprs try to add a task to project or a target to a task etc. I don't
>> like this kind of behaviour generally. It is alright to have a unified
>> interface for it all (I am actually building this - the Camelot Container
>> API in Avalon atm) but I don't think it is good in our case.
>I really don't get the whole container-contained argument. As a rule, I
>don't like to restrict someone from doing something just because it was
>something that I didn't forsee them wanting to do. 

agreed - have a look at some other abstractions I put in myrmidon because
people have asked for them before ;)

>Take your example of
>assigning a project under a task. I suppose I could write code to disallow
>this, but in my world, I see every Task (including Project) as a method call
>with a return type.

hmmm - return type I like that. Could you expand on how you see the role of
return types being used in Ant?

>Suppose the return type for a project had some value to that Task. It could.
>We just have to open our minds a little. I am not one that subscribes to the
>concept that we must protect the developer from themselves. 

Then why are you using java ? ;)

>If the argument
>is that this tool is used by someone with the technical abilities of my Mom
>(none to speak of, but a great cook!), then I still say that Ant core should
>remain as I sketched it, and the particular implementation that is exposed
>to these "delicate users" is more restrictive. I don't want to alienate the
>power users however.

Ever heard the saying "The path to perl/make was paved with good
intentions" ? ;) Each of these tools started out simple but look them now.
Regardless of whether you like them or not they are not exactly
maintainable languages. I was told by a perl advocate once that if you
can't do the same task at least 15 different ways then it is time to extend
perl ;)

Just because you can is not good enough reason to do - this is flexability
syndrome at it's worst and is rightly feared by most largish development
projects ;)

Enable power sure - but keep it simple for 80% of things or else you will
go thorugh hell and suffer from feature creep. We have deliberately
avoiding the vast majority of user requests because it would add to much
complexity - I doubt anyone has changed their mind ;)

>>  The target/project objects have no reason to be proxied while tasks do.
>I have a real problem with the concept of these Proxy objects. I am not sure
>I see the benefit of them in the existing structure, and I certainly don't
>see the need for them in the future. What is accomplished through the use of
>these proxies that is worth the mass of code to support them?

<echo message="To evaluate ${foo} at interpret time" />

>It can't be performance, because my informal benchmarks show object creation
>for a 100 node build script to be below 100 ms. Proxies do produce a smaller
>memory footprint (but not by much), but in relation to the memory that
>javac, jar and javadoc use it is a pittance.

nope - proxied tasks actually slightly slow down execution I suspect - thou
not enough for it to be an issue.

>frANTic, as it exists now, does not use these proxy semantics and the code
>is much cleaner for it. I think that foregoing the proxy pattern will
>enhance the ability of scripting at runtime as well.

perhaps - but you have modeled frANTic in a manner similar to original ant
- through much pain and suffering it evolved and I don't think it will ever
go back to raw task object tree.

>> Besides does swing alow buttons to be contained by buttons. If so who does
>> message handling and do you think that it is intuitive? ;)
>Swing does allow this, and the message handling is performed by the button
>that received the user input.

But both receive the input because it is lightweight objects ;)

>> I  think it would be more code size - mainly because we use proxies.
>The payoff I see from frANTic is that we will not have to focus on the core
>of Ant any longer. The capabilities of Ant lie in the Tasks, not the core.
>If something as simple as a Task Execution Engine performs its job properly,
>it will provide a solid and extensible framework for Task authors to let
>their imagination run free.

Thats the way ant core will be regardless of which proposal is adopted.



| "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               |

View raw message