ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject RE: Parameterized "task-function"
Date Fri, 12 Jan 2001 06:10:58 GMT
At 11:46  11/1/01 -0500, Rosen, Alex wrote:
>Maybe I'm missing something, but... to me this approach feels totally
backward.
>It reminds me of the systems for simulating parameterized types with
>preprocessor macros, before C++ templates came along, which was an unnatural
>hack.

perhaps - but we already have "methods" via ant-call and they were
generally found to be lacking. A few days ago jerry.huth@eng.sun.com posted
something to ant-dev titled "The RIGHT Direction for ANT" which pretty much
reverted me to thinking that static templating is way to go. He also
advocated separation between rules/templates and data operated on. If you
think it is backward you should pop onto ant-dev and respond to this
message ;) 

>Sorry to say, what I really want to do is "call a method" - that's what would
>feel natural to me. What you're doing is adding a preprocessor, which feels
>backwards - the method comes first, then the method call, instead of the
other
>way around.

ant-call is your friend. It is here and now ;) Thou it may not be in the
future - who can tell ;)

>I'm no language expert, but to me Ant (and building in general) feels like a
>declarative language on top of a procedural language. 

yep.

>You want to use a
>declarative language to figure out what to build, but you really want to
use a
>procedural language to describe how to build it. 

essentially. All procedural-ness is hidden in tasks and tasks should NOT
interact with each other. 

>Trying to extend the declarativeness all the way down seems like a big
mistake...

maybe.

>Is there anything declarative about describing how to build something (as
>opposed to describing what to build)?

I am not sure what you mean. Declarative is a representation and doesn't
govern these sorts of things. I am not even sure thats a useful distinction
to make. The declarative approach can both describe a process (how) and the
data (what) so I am not sure what you are saying.

The reason procedural is avoided is because it tends to be brittle,
difficult to maintain, difficult to understand etc. In simple cases
procedural wins out in simplicty because declarative has a high entry cost
but for these exceptions we have the script task.

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               |
*-----------------------------------------------------*


Mime
View raw message