=> On Mon, 11 Jun 2001 17:56:31 -0700 (PDT), Roger Vaughn <[EMAIL PROTECTED]> said:
>>> Say we'd add foreach to the core - and I'm more and more leaning towards >>> it (making myself a heretic, I guess 8-) - and we already have those many >>> cases where we successfully anticipated the need for iterations like >>> javac, execon, apply and in the future anton, javaon. What can we do to >>> make user chose the "right" thing? Having now read the requirements doc for ant2, I think that keeping foreach out of the core, but anticipating that those who want it will grab it, is the best way to present the 'right' way without being draconian. I, for one, would drop out of the debate were that decided. > First we had <exec>. Then came <execon>, i.e. exec for each member of a > fileset. Now we see anton, javaon, etc. in the future. But is this the start > of a trend: exec/execon, ant/anton, chmod/chmodon, delete/deleteon, > echo/echoon, etc.? (Yes, I know some of these deal with filesets natively - > I'm simply making a point.) > Are we now going to have individual and iterating versions of every task? I assert that tasks should, where this is sane, operate on a list of items. This list may only contain one item. > It would seem to make far more sense to me to extract the iteration code into > its own construct, and keep the individual tasks pure. This would seem to > involve far less code, simpler maintenance, and more flexibility in the build > files. It also formally forces task writers to accept heinous inefficiencies when it is appropriate to operate on filesets. foreach (distfiles) add one file to a tar ... ? Viewing builds as functional transformations on filesets is a powerful abstraction. I think we should still phrase things in that idiom wherever practicable, (which I still say is everywhere) but let people use the more complex (IMHO), but evidently more comprehensible, iterative idiom when they feel the need. - Allen S. Rout
