[Fwd: Approach to Conditionals: SOMETHING USEFUL ON THIS TOPIC]

[ma...@sedonacorp.com]

i should have copied the developer group on the original message,
but here goes..... (this is in response to a thread on the ant-user group)


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

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