ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craeg K. Strong" <cstr...@arielpartners.com>
Subject Re: [PATCH] PropertyCopy and Foreach (NEW OPTIONAL TASKS)
Date Tue, 25 Sep 2001 16:23:27 GMT
Matt:  

Jose and Stefan have expressed technical reasons why a particular
order of execution cannot/should not be guaranteed by foreach.  
I understand their point of view, but IMHO there is a more serious
underlying philosophical reason why this would not be a good thing.

When you say "people are used to it executing in a defined order"
To me this says there is some kind of implied dependency between
the tasks.  This would represent a loss of information, because you
then would have dependencies that are not captured explicitly in Ant.

I have created a fairly extensive set of Ant buildfiles, and have several
places where I perform tasks on a set of items.  While some kind of looping
or foreach task would make my buildfiles more concise, it would not
otherwise change the functionality.  No particular ordering is required.

Can you give an example where you would need an ordered collection,
rather than a set?

--Craeg

Jose Alberto Fernandez wrote:

>Ant is not a Scripting/Programming tool. It expresses in a declarative fashion the way
to build something. You do not specify the total order of all targets. It is upto ANT's dependecy
engine to decide the order of execution as long as dependencies are preserved. There is no
reason why FOREACH should work any different. If the iterations are computed based on <fileset>
or some other, then we need to be aware that such constructs are SETS and such there is no
order associated with its elements. And there is little way to guarantee that it will be iterated
in the sameorder on every OS that may ever exists.
>
>Jose Alberto
>
>From: "Matthew Inger" <matti@sedonacorp.com>
>
>>I think that not guaranteeing the order of
>>a foreach task is a very bad thing.  It's
>>a scripting/programming style task, and people
>>are used to it executing in a defined order,
>>and to change that at some later date would
>>produced behavior that some might not expect.
>>

>>



Mime
View raw message