----- Original Message -----
From: "Peter Donald" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
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
ant.
> >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?
Jason
