ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: Approach to Conditionals: SOMETHING USEFUL ON THIS TOPIC
Date Wed, 04 Jul 2001 03:04:31 GMT
This will be provided by Ant2. I think we have even voted on it. Except we 
called it ContainerTask. 

On Wed,  4 Jul 2001 05:37, matt.inger@sedonacorp.com wrote:
> ok, well i've been peeking at the "for-each"  thread for a while, and can
> see where it's going.  The bottom line is that many users see the need for
> some form of simple control flow structures.  Shouldn't tools
> be driven by the basic user requirements?  That's my $.02 on that
> topic.  And i won't get into the debate on inclusion into the core,
> but rather support for users to create their own conditionals.
>
> Onto something more useful.  It would be nice to modify
> the ant core to be able to have one task execute a series of other
> tasks.  This would allow people to create their own types of custom
> conditionals which would work from one version of ant to another.
> Currently, you could in create a Task subsclass like:
> ( I already have done this, so it works )
>
> // ***************** BEGIN CODE
>
> public class TaskContainer extends Task
> {
>    public Task createAnt() { ... };
>     public Task createAntCall() { ... };
>
>    public void execute()  throws BuildException
>    { /* execute all the created tasks underneath this one */ };
> }
>
> public class MyConditional extends TaskContainer
> {
>    public void execute() throws BuildException
>   {
>      if (condition.evaluate()) super.execute();
>      else { /* do some elseif style stuff here in the same manner */ }
>   }
>
>    ....
> }
>
> // ************************** END CODE
>
> but that creates trouble from one version of ant to another, as you have
> to make create methods in the TaskContainer for every builtin and optional
> task that ant defines.  Plus the above way has the drawback of not being
> able to put custom tasks inside these task containers.  What would be an
> elegant way to do this is to create the following class:
>
> // ********************* BEGIN CODE
>
> package org.apache.tools.ant;
>
> import java.util.ArrayList;
> import java.util.Collections;
> import java.util.Iterator;
> import java.util.List;
>
> public class TaskContainer extends Task
> {
>     protected List subtasks = new ArrayList();
>
>     void addSubtask(Task t)
>     {
>         subtasks.add(t);
>     }
>
>     List getSubtasks()
>     {
>         return Collections.unmodifiableList(subtasks);
>     }
>
>     protected void executeSubtasks()
>         throws BuildException
>     {
>         Iterator it = subtasks.iterator();
>         while (it.hasNext())
>         {
>             Task t = (Task)(it.next());
>             t.execute();
>         }
>     }
>
>     public void execute()
>         throws BuildException
>     {
>         executeSubtasks();
>     }
> }
> // ********************* END CODE *************
>
> and then in IntrospectorHelper.java:
>
> // ********************** BEGIN CODE
>     public Object createElement(Object element, String elementName)
>         throws BuildException {
>         NestedCreator nc = (NestedCreator) nestedCreators.get(elementName);
>
>         if (nc == null && element instanceof TaskContainer)
>         {
>             TaskContainer task = (TaskContainer)element;
>             Project p = task.getProject();
>             Map tasks = p.getTaskDefinitions();
>             if (tasks.containsKey(elementName))
>             {
>                 Task t = p.createTask(elementName);
>                 task.addSubtask(t);
>                 return t;
>             }
>         }
>         else if (nc == null) {
>             String msg = "Class " + element.getClass().getName() +
>                 " doesn't support the nested \"" + elementName + "\"
> element"; throw new BuildException(msg);
>         }
>         ....
>    }
>
> // ********************* END CODE ********************
>
> and then you could extend TaskContainer as in the first example,
> and simply call super.execute() whenever you wanted to execute
> all the tasks that were added to the container.  It doesn't throw off
> the basic design of ant, and is a relatively simple and innocuous way
> to allow users to add their own conditionals (or support future
> conditionals in the core, if it's decided that they are to be added at
> a later date).
>
> Thoughts anyone?
>
> Peter Donald wrote:
> > On Wed,  4 Jul 2001 01:06, Chris Greenlee wrote:
> > > Peter (Donald),
> > >
> > > <offtopic>
> > > Apologies, but your tone is quite often abusive.  People who post
> > > thoughtful comments ought not to be insulted just because you disagree
> > > with them.
> > > </offtopic>
> >
> > If I post the same thing 15 times does it become thoughtful the 15th
> > time? I am not sure how long you have been on this list but he has been
> > repeating like a drone the same things over and over and over again for a
> > few months now. We listened the first time but now it is just noise. I
> > thought I was relatively polite given the history.
> >
> > > Now, to continue this thread with some responses to your objections, as
> > > I have seen them:
> > >
> > > Objection #1: Adding flow-of-control tasks makes Ant more complex for
> > > the user.
> > >
> > > Response #1: Adding more tasks -- any tasks -- increases the complexity
> > > of the tool, in a trivial sense: there are more tasks to choose from,
> > > and so choosing the appropriate task to use requires reading more
> > > documentation.  Adding if/then, switch, foreach, etc. tasks or
> > > constructs will, in this trivial sense, increase the complexity of the
> > > tool.  However, people are not required to use each and every task
> > > provided with Ant.  I myself use only about 14 Ant tasks -- <ant/>,
> > > <antcall/>, <available/>, <cvs/>, <ftp/>, <foreach/>,
<jar/>, <javac/>,
> > > <javadoc/>, <junit/>, <junitreport/>, <javadoc/>, <property/>,
and
> > > <style/> -- while there are over 40 just in the core.  Adding more
> > > tasks gives the user the ability to create more complex build scripts,
> > > but it does not require them to do so.  Moreover, flow-of-control tasks
> > > in particular, when properly used, may well simplify build scripts,
> > > making them smaller, easier to understand, and easier to maintain.
> >
> > Put bluntly, the vast body of research in natural language and artificial
> > language theory disagrees with you. If you look at the evolution of
> > natural languages then it becomes obvious. More evolved languages have
> > smaller sets of symbols but are able to express more meanings. Compare
> > modern English to ancient Egyptian. English has 26 symbols while ancient
> > Egyptian has a bunch - lets say 5000 (no idea just guessing). English can
> > expresse more meanings despite this. The reason for it is because of all
> > those extra word classes and rules to manipulate (aka flow control for
> > NL). English is the more difficult language to learn despite having fewer
> > essential symbols.
> >
> > Theres similar findings in artificial language theory. Why do languages
> > like lisp with all their power not see use. It is not because they are
> > not good but more because they require more knowledge from user.
> >
> > Adding flow control to ant also increases knowledge required to manage
> > build files. This is great if you are build engineers but sucks
> > otherwise. Not surprisingly the build engineers on the list want it to be
> > added ;) You may claim that addition of a few tasks is not a biggie.
> > However if you look through the archives you will see there is a large
> > number of side effects from this decision and it will decisions in
> > unrelated areas. It will also open path to other requested functionality.
> >
> > I am a believer in doing one thing well. Currently ant does too many
> > scripty things and encourages too many bad practices. These will
> > hopefully be eliminated in ant2 but who can tell at this stage.
> >
> > > Objection #2: Adding flow-of-control tasks makes Ant more complex for
> > > the maintainers.
> >
> > Never been an objection per se. The objection was (1) which would lead to
> > (2) because developers would have to support people who do stupid things
> > but aren't educated enough to know when they are doing stupid things.
> >
> > > Objection #3: Ant is not a scripting language, and adding
> > > flow-of-control tasks would make Ant a scripting language.
> > >
> > > Reponse #3: Most scripting languages are characterized not merely by
> > > flow-of-control operators, but by extensive string manipulation
> > > libraries, lack of type checking, implicit variable declarations, etc..
> > > Adding flow-of-control tasks to Ant will not suffice to make Ant a full
> > > fledged scripting language, or anything close.
> >
> > The addition of flow control would not be the end of it. If you look over
> > the archives, us "thought police" (aka ant-dev) have been asked for the
> > same things you mention. We already have or will have "lack of type
> > checking, implicit variable declarations". The other thing that we are
> > always asked for is logic operators. The only thing keeping ant from
> > being a scripting language in ant2 will be the lack of flow control. The
> > rest we will have (and I will be providing certain flow control tasks
> > outside core anyways).
> >
> > 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               |
> >
> > *-----------------------------------------------------*
>
> --
> Matt Inger (matt.inger@sedonacorp.com)
> Sedona Corporation
> 455 S. Gulph Road, Suite 300
> King of Prussia, PA 19406
> (484) 679-2213
> "Self-respect - the secure feeling that no one,
>  as yet, is suspicious." -H.L. Mencken

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

Mime
View raw message