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 ([EMAIL PROTECTED])
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
