Quite elegant! I like it, which probably means Peter D will -1 it :-) -Peter > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, July 03, 2001 12:38 PM > To: [EMAIL PROTECTED] > 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 ([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 > > >
