ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Uther <will+...@cs.cmu.edu>
Subject Re: Tasks containing other tasks (was: Subtasks within tasks)
Date Fri, 25 Feb 2000 17:57:54 GMT
--On Fri, Feb 25, 2000 12:03 AM -0800 costin@eng.sun.com wrote:

>> <switch name="os.name">
>> </switch>
> 
> I was afraid of that....

I don't think I've ever managed to rate 'scary' before :).

> I think we should split the problem in 2:
> 
> 1. How to deal with the case of 
>     <foo>
>        <bar>
>     </foo>
> Where we can't have createBar() ( because we want foo to support dynamic 
> sub-elements, including elements defined at runtime with taskdef ).
> 
> In your particular case, having foo implement an interface will work and
> it's a good solution, but I was thinking at the general case, when the
> child doens't have to be a task - this is not the only situation when you
> need a dynamic sub-element. 

Ahhh, ok.  Your previous suggestion makes much more sense now :).

from Costin's previous commment:
> For "<foo>":
> 
> - first try createFoo() 
> - if no such method is found, try to create a foo object ( based on 
> existing taskdefs )
> - try addFoo( foo ) 
> - if no such method try addBar() where Bar is an interface implemented by
> foo ( or superclass).

I would suggest is moving from addFoo() and addBar() to just an
addElement(elt) method.  Instead of using the method name to do the
specialization, you could use the type of the formal parameter.  (e.g.
addElement(foo myFoo) vs addElement(bar myBar))

> 2. <case>, <macro>, etc. We need a lot of thinking before adding such
> thing in ant. The reason I asked "what is a sub-task/ task container"
> is simple - what you want is not a simple "patch" or incremental change,
> but a radical change in the ant architecture and idea. 

Actually, from the perspective of someone who has just arrived, it looks
like a logical next step.  Having looked at implementing it, I agree it
needs a change of semantics internally - but you can see the other thread
for that.

> Ant is not a programming language, and adding if and loop will make it a
> PL ( by Turing machine def). It's nothing wrong with inventing a new PL,
> it's just that many people like ant because it's simple and not yet
> another PL.

I am a strong believer in the KISS principle.  I use java and not C++ :).
However, at present you cannot replace fairly simple makefiles with ANT
because it lacks this functionality.  From the point of view of someone
looking for a cross-platform build utility this is somewhat frustrating.

You should make things as simple as possible, but no simpler.  Right now
ANT falls into the 'too simple' category.

Adding if and loop will make ANT turing complete.  However, from a KISS
standpoint there is a big difference between that and C++.

> I think both are very serious design issues, and I think we should wait
> and have a general agreement before adding them ( I'm -1 on both ). 

Speaking of waiting, has anyone looked at those Mac patches I posted?

later,

\x/ill            :-}


Mime
View raw message