ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Vogel <pvo...@arsin.com>
Subject RE: Approach to Conditionals: SOMETHING USEFUL ON THIS TOPIC
Date Tue, 03 Jul 2001 22:05:07 GMT
Quite elegant!  I like it, which probably means Peter D will -1 it :-)

-Peter

> -----Original Message-----
> From: matt.inger@sedonacorp.com [mailto:matt.inger@sedonacorp.com]
> Sent: Tuesday, July 03, 2001 12:38 PM
> To: ant-user@jakarta.apache.org
> Subject: Approach to Conditionals: SOMETHING USEFUL ON THIS TOPIC
> 
> 
> 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
> 
> 
> 

Mime
View raw message