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