ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From matt.in...@sedonacorp.com
Subject Re: Approach to Conditionals: SOMETHING USEFUL ON THIS TOPIC
Date Thu, 05 Jul 2001 14:14:35 GMT
Peter,

A couple of notes.  I definitely appreciate your (and the rest of the ant-dev)
teams efforts.  Ant is taking over as our installer.  Right now it's all based
on running on the command line with a properties file.  Some of it involves
subprojects,
which prompt the user when required properties are not found.  Eventually,
it will probably have a gui front end on it, which will edit the properties,
and kick off ant.

I understand that your vision of ant does not involve making it a scripting
language.
However, like myself, most users need some basic constructs for flow control.
I think the ContainerTask will definately be a step in that direction allowing
users to develop their own tasks.  But, in a lot of cases, the people
developing the ant input files are not necessarily java programmers,
and could not really code up their own tasks, or effectively make their
own conditionals.  I myself am willing to do that, but most users are not
either willing or capable of doing this. I just happen to work for a small
company,
and don't have the luxury of having someone else build my install scripts for
me.

I'm not saying you have to provide a complete flow control solution, but at
lease some basic constructs such as "if/elseif/else", and "foreach".  Switch
is not necessary, as it can be done with an if (and would in effect probably
be the same code anyway).

It would serve 2 purposes..

1) it would make user's lives easier
2) it would make your life easier because you'd have to stop
     hearing the same request over and over again.


just my $.02

And i'm more than willing to contribute to the development effort.



Peter Donald wrote:

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

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