--- [EMAIL PROTECTED] wrote: > 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.
Someone on the list has already written a foreach task - it's not part of the *core*, but including it in the distro would be helpful. > > 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. I agree. This does *not*, however, include tasks such as exec, ant, echo, etc. > 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 ... ? Now that's absurd. I can't think of any reason why the Ant authors would do such a thing, nor would I even think to ask it. Tar naturally operates on a set of input files, as do javac and many other tasks. Exec, however, does *not*. In fact, the internal representation of execon is equivalent to "foreach f in fileset, exec x(f)." How then, is representing this explicitly in the build file less efficient? The point on the table is that Ant is evolving so that it contains *two* copies of many tasks - a single file version ala exec, and a fileset version ala execon. That fileset code will get replicated (and therefore must be maintained) in several places - execon, anton, etc. How does it not make sense to isolate the common iteration code in its own construct? > 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. Yes, but transformation of filesets is not sufficient. Large system builds must contend with much more than just transforming files into other files. The large number of requests for iteration on this list proves that it is a needed, understood feature. Why then the extreme resistance? Not one person has yet even attempted to explain why iteration is "bad", though several have tried to offer alternatives. I also fail to see how iteration is complex. I use loops every day, no problems. Part of make's failing was the fact that we frequently needed to resort to incomprehensible hacks to express simple concepts. Do we want to repeat that in Ant? Iteration is simple, understood, and needed. Now what's wrong with that? roger __________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/
