ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Rosenberg" <>
Subject Re: Parameterized "task-function"
Date Mon, 15 Jan 2001 08:03:51 GMT

----- Original Message ----- 
From: "Peter Donald" <>
To: <>
Cc: <>
Sent: Monday, January 15, 2001 2:29 AM
Subject: Re: Parameterized "task-function"

> >> >2. direct calling of targets, e.g. <call-target> (not antcall!),
> >> >    with parameterized arguments passed to the target.
> >> 
> >> will be in Ant2.0
> >> 
> >Hadn't heard that, in fact it certainly seems like you've been on
> >my case when I've suggested the need for this.  Perhaps it was
> >someone else....
> Well it is Ant1.x and it is implemented in at least my proposal for Ant2.0.
> In general it is of limited usefulness thou there are some cases that it
> does become useful. I don't object to it - I object to
> if/then/else/case/whatever tasks ;)

How can you do this in Ant1.x?  Without antcall, I mean?

> >> >3. tasks then, need to be dynamically reusable and reconfigurable,
> >> >    so that when they are traversed as part of call-target, they
> >> >    represent fresh instantiations of the task, so that new filesets,
> >> >    etc., can be attached to them.
> >> 
> >> will be in Ant2.0
> >> 
> >
> >My god, Ant2.0 is getting more procedural and less declarative
> >every day.
> ummm ... you should really go read up on what is declarative/procedural
> distinction. This actually makes it more declarative ;)

It may be declarative to simply define a function in isolation.  But it is
certainly procedural to define and clean up the conditions upon which
the function will be called.  Referencing a reusable subroutine, allows and
facilitates the clean procedural use of the task.  If the task is cumbersome
and requires it's own self-contained execution context, as in the case
of antcall, I'd say it is more declarative.

Not much to read up on declarative/procedural debates.  In the end
everyone is just talking about the same thing anyway.

> essentially - that would turn ant into a scripting language. Not something
> that will happen. (at least not for build files).

And I respond that you are in denial, becaue it already is a scripting
language, nothing now, after the fact, will get the credit for turning
it into such.

> >When you call mytarget, any
> >state it might set will be lost once the antcall finishes, which makes it
> >appear that it never occurred to the rest of the processing of the ant
> >project.
> Fixed in the myrmidon proposal - it is even very performance sensitive.

Who or what is myrmidon?  Is this something different than Ant2.0?

> >Why not have a simple, intuitive task
> >for a loop, much in the vein of everything else that is intuitive and
> >straightforward about Ant.  The intuitive feel will be lost when
> >you start going the xslt route:
> perhaps - but if we include whiles then next will be if, then do/while,
> then for, then for-each etc. 

Omigod, the sky is falling!

> XSLT already does all this and we don't want
> to reinvent the wheel. 

Reinvent what wheel?  Nothing magical about loops.
Can't be too hard, me thinks.  Or are you still objecting
on declarative vs. procedural grounds?

> XSLT is standard and much more powerful - and
> besides we don't have to do anymuch work to get it going.

Writing iteration via XSLT sound more cumbersome and
unintuitive than just implementing a few simple loops in

> >Doesn't look too complicated to me, in fact, it's simple and intuitive.
> >Dare I say, "it's declarative!".  How do you specify iteration in a
> >declarative manner, anyway?
> You generally can not specify iteration as such. You can specify an
> operation on a set of classes thou or sequence.
> So in pseudo SQL it would be something like
> doOperation( select * from Foo );

So, is SQL considered the ideal declarative language?  Is the test
then, if you can do it in pseudo SQL, it can be done declaratively?

What happens if you want to do a select statement, but you want
to sort the result, via an 'orderBy' construct.  Have we then crossed
the line from simple set theory to iterated/ordered set theory?

Too many theories, methinks.

> >Personally, I think if we are going to be purists here, we need to
> >get rid of both <script> and <antcall>.  And once you do that,
> >inevitably you will have to cave to the proceduralist pressures.
> >But by allowing <script>, you are attempting to hide your head
> >in the sand "It's not procedural, really, but gee, if you really need
> >it, you can use javascript via <script>".
> actually - i don't think script will be able interact with object model (or
> at least I no longer see any good reason to allow it) - it will be more
> useful for ad-hoc operations. Like calculating the value of PI times
> current day divided by the phase of the moon ;)

How will this be accomplished.  Will you no longer make the
Ant java classes visible to JavaScript?  How can you do that?  Or
are you considering removing Rhino/JavaScript from the allowable
<script> language attributes?


View raw message