ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jose Alberto Fernandez <jofer...@us.oracle.com>
Subject Re: Tasks containing other tasks (was: Subtasks within tasks)
Date Sun, 27 Feb 2000 01:21:58 GMT


James Duncan Davidson wrote:
> 
> > <switch name="os.name">
> > <case value="Mac OS">
> > <javac ..... />
> > </case>
> > <case value="Win*">
> > <javac ..... />
> > </case>
> > <deafult>
> > <Deltree ..... />
> > </default>
> > </switch>
> 
> The problem that I have with this is that it introduces logic into the
> antfile. It was an explicit design goal of mine when I first wrote ant for
> the files to be totally declaritive and *all* logic occurs in the task. If
> you want to write specialized logic, you can -- it's easy enough to add
> tasks via the <taskdef...> -- now, if the group wants to change course on
> that, that's something I can't control, but I won't welcome it.
> 

There is nothing declarative about what you are saying. You do not write
something more declarative by constantly adding more words to the
language.
How can anyone understand what you are declaring if you cannot
understand
the words (<taskdef...>). 

Something is declarative if you can understand it based on a mostly
limited
number of concepts that one can combine to achieve the required meaning.
To me, once we have some critical mass, additional <taksdef...> should
only
be necessary when trying to use ANT on some new environment, something
different from bilding (java) applications. In principle, any task that
requires a topological ordering at its hard, can use the ANT machinery
but most probably a completely different vocabulary (<taskdef...>).

> This means that I would prefer not to see anything like an if/then/else,
> for, or switch implemented in this fashion. If you want to build logic, do
> it in Java. If you want to describe the project, do it in XML.
> 
> .duncan

If we want ANT to really be able to succeed in the large as well as the
small
we will need will eventually need some way to define new tasks by
composing
existing tasks. In any type of composition we will need some way pick
between alternatives.

Now, I may agree with you that <select> <if> <foreach> may not be the
right 
declarative means and that we would be polluting ANT with the evils of 
procedural programming. I would suggest a different set of composing
operations (more declarative in my opinion).

1) A way to define new tasks by naming other tasks:

<taskdef .... >
  <task1.../>
  <task2...> ... <task2>
<taskdef>

2) Something like lisp's mapcar so that one can apply
the same task to a sequence of values. So one can
say things like apply this tasks to all this values.
This is declarative in the sense that there is no order
involved in this application, in principle one could
apply the tasks in parallel or backwards or whatever.

3) Some way to select between alternatives, here something 
like a pattern matching to define different cases.

Now with this three concepts we can do very sofisticated 
things in a very declarative manner. Notice the difference 
between this and MACROS in the sense of make. Macros are
not declarative at all because in general you cannot define
what they mean until you expand them fully. Here every construct
is meaninful in its own right.
Mime
View raw message