You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by ma...@sedonacorp.com on 2001/07/03 21:37:43 UTC
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
Re: Approach to Conditionals: SOMETHING USEFUL ON THIS TOPIC
Posted by Peter Donald <do...@apache.org>.
On Fri, 6 Jul 2001 00:14, matt.inger@sedonacorp.com wrote:
> 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.
Agreed. Theres a group of peeps I am currently working with to make something
like Ant work as a complete command input replacement. If you think unix then
think of it as a replacement for crontab, initab and some other scripts. In
that case we need foreach, if, switch (and I have actually already coded them
up). However they will never be available from the ant core website.
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 |
*-----------------------------------------------------*
Re: Approach to Conditionals: SOMETHING USEFUL ON THIS TOPIC
Posted by ma...@sedonacorp.com.
Excellent.... For now, then I guess I keep a patched version of the Introspector
helper
in my own jarfile, and put that before ant.jar in the classpath....
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
RCS (was: Approach to Conditionals: SOMETHING USEFUL ON THIS TOPIC)
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 05 Jul 2001, matt inger <ma...@sedonacorp.com> wrote:
> speaking of <cvs>, are there any libraries out there for <rcs>? I
> know it's old and decrepit, but that's what i'm stuck with.
Well, the cvs task is a simple wrapper around executing the command
line cvs utility, doing the same as a wrapper around co/ci would not
be that difficult.
All it takes is somebody with the need and the time to implement it 8-)
Stefan
Re: Approach to Conditionals: SOMETHING USEFUL ON THIS TOPIC
Posted by ma...@sedonacorp.com.
i have no problem with that. in any case, speaking of <cvs>, are there
any libraries out there for <rcs>? I know it's old and decrepit, but
that's
what i'm stuck with.
Stefan Bodewig wrote:
> On Thu, 05 Jul 2001, matt inger <ma...@sedonacorp.com> wrote:
>
> > 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.
>
> The idea here is that there will be a "standard" foreach task (and
> friends) in a repository of optional tasks, it will just not be part
> of the very core of Ant (just like many current built-in tasks will
> probably be demoted to optional tasks - <sql>, <cvs> and many others).
>
> Stefan
--
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
Re: Approach to Conditionals: SOMETHING USEFUL ON THIS TOPIC
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 05 Jul 2001, matt inger <ma...@sedonacorp.com> wrote:
> 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.
The idea here is that there will be a "standard" foreach task (and
friends) in a repository of optional tasks, it will just not be part
of the very core of Ant (just like many current built-in tasks will
probably be demoted to optional tasks - <sql>, <cvs> and many others).
Stefan
Re: Approach to Conditionals: SOMETHING USEFUL ON THIS TOPIC
Posted by ma...@sedonacorp.com.
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
Re: Approach to Conditionals: SOMETHING USEFUL ON THIS TOPIC
Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
I called mine TaskContainer :-)
----- Original Message -----
From: "Peter Donald" <do...@apache.org>
To: <an...@jakarta.apache.org>
Sent: Wednesday, July 04, 2001 1:04 PM
Subject: Re: Approach to Conditionals: SOMETHING USEFUL ON THIS TOPIC
> This will be provided by Ant2. I think we have even voted on it. Except
we
> called it ContainerTask.
>
Re: Approach to Conditionals: SOMETHING USEFUL ON THIS TOPIC
Posted by Peter Donald <do...@apache.org>.
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 |
*-----------------------------------------------------*