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>
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.
Objection #2: Adding flow-of-control tasks makes Ant more complex for
the maintainers.
Reponse #2: Yes, but so does adding any other task. If this is
burdensome, there are several people who have volunteered to contribute
their efforts to maintaining these tasks. And to include basic
flow-of-control tasks, only two or three would need to be added:
if/then/else and foreach, and perhaps (although I think it unnecessary
in a build tool) while.
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.
I am actually interested in hearing your responses to my responses. I
hope you'll take them seriously. I can certainly be persuaded that
flow-of-control tasks aren't appropriate for Ant, but I'd need these
answered first.
Cheers,
Chris Greenlee
> -----Original Message-----
> From: Peter Donald [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, July 03, 2001 4:20 AM
> To: [EMAIL PROTECTED]
> Subject: Re: for-each (another proposal)
>
>
> On Tue, 3 Jul 2001 18:39, Peter Vogel wrote:
> > It's interesting that you say this. Because the same is true for
> > me, and has been for the 12 or so years I've been implementing
> > builds for one thing or another -- developers (whether C, C++,
> > Java or otherwise) generally consider build automation "beneath"
> > them (though they could not live without it) and so do not want to
> > be bothered with the intricacies of *any* build tool, whether it
> > be make, Ant, or (God forbid) shell scripts. Therefore, to me the
> > *key* requirement for a build tool is that it supports the
> construction
> > of an "infrastructure" which defines a project/company specific
> > environment of *conceptually simple* constructs that are
> reusable from
> > project to project within the company and where a project
> build file is
> > a "no brainer" for the developers -- the intelligence is
> embedded in the
> > infrastructure, where it can be explained to the small
> cadre of people who
> > care or have interest in such things, and where it can be
> appropriately
> > grown to meet the evolving needs of the company.
>
> Similar arguements are made for things like TCL or lisp.
> Given a few basic
> operations (5-6 in those cases) all the rest of
> infrastructure comes for free
> (or via add in modules).
>
> Neither really took off commercially (well except for maybe
> tcl but some
> would argue that is because of tk) not because they weren't
> good. But because
> to use it effectively required substantial knowledge and
> understanding.
> Things that people weren't willing to invest in to PLs. Do
> you think they are
> even more likely to invest it in a build infrastructure?
> (Before you answer
> that look at how most non-build engineers deal with Make).
>
> > So, here's my problem with all your "template" concepts:
> they require that
> > I (and, more importantly, others who will inherit the
> infrastructure that
> > I construct, whether it be 6 weeks or 6 years from now) study and
> > understand yet another tool/language/etc. to do what can be
> done neatly and
> > cleanly within
> > the core of ant in a far simpler manner conceptually.
>
> So let me see if I have got this correct. Build engineers
> want to do complex
> things. Hence you want complexity imported into ant
> "language" making it
> possible to do what you want. Because in your situation you
> have some one
> that can be dedicated to maintiang build process. It doesn't
> matter to you
> that other projects that don't need a build engineer will be
> paying for
> complexity because you will never be in that situation.
>
> And this is all to avoid learning a templating language. Even
> though that
> language is potentially a standard language whos basics could
> be understood
> in .... what about 40 minutes? Well all I can say is ... boo hoo.
>
> 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 |
> *-----------------------------------------------------*
>
