----- Original Message -----
From: "Alejandro Abdelnur" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, September 21, 2001 11:20 AM
Subject: Re: [PATCH] PropertyCopy and Foreach (NEW OPTIONAL TASKS)
> matthew,
>
> i've been there already, submitted code doing that, it has been rejected.
>
> it is not the first time, or second time, that these features are
proposed. i
> think the the folks driving the evolution of ant should start considering
> these features again, they should listen a little more of what
developers/user
> want/need.
>
Alejandro,
Nobody denies that the ability to act on a set of items is a good thing.
However, it has to be done in a way which is clean and compatible with
current and future thinking of what ant is. And that thinking comes down to
'a declarative means of specifying a build which is readable by other people
or even yourself months after you wrote it'. Keeping it declarative gives a
number of advantages, most notably in flexibility of implementation. Keeping
it simple means that anyone can start using it, and you never end up with
those horrors of makefiles which big projects tend to acquire.
If you were to take a quick glance at the ant2 requirements, you would note
the section in control flow: "The execon and apply tasks can be used to
iterate over a set of files as the (planed for Ant2) javaon and anton tasks
will do. ". Which means that the need to iterate has been noted, and will be
supported. Before that can be done, however, we need to come up with a means
of specifying a set of items to iterate over, and a clean method of calling
ant tasks iteratively. I would encourage you to take part in the design
discussions related to this, and even contribute code, as that way your
needs and experience can influence the outcome.
> fyi:
(out of order)
> for looping i've implemented the "xantcall" target, extending the
"antcall"
> target that supports iterations:
>
> <xantcall target="TARGET" iterate="LIST" iterator="VAR"/>
>
> where VAR is the name of the variable that will have the element of the
> current iteration.
Its an interesting little hack, but it pushes the boundary of what can be
called 'declarative', what with all the mention of 'iteration' in the
statement. I believe what the development team really envisages in terms of
set/list operations is something more like SELECT in SQL, rather than an XML
representation of a for() loop.
One of the big flaws of your approach is that once you have an iterator, you
need to be able to use it, which is presumably why you've made the next
change
> for embedded properties i modified the project helper, so you can use
embedded
> variables "a.${b}.c" everywhere.
Most languages don't let you dynamically produce variable name strings on
the fly, because it produces scary looking code that is hard to work with.
Some of the purely interpreted languages are slightly different, APL and VB
do let you construct a statement in a string, so this kind of thing could be
done there, but it tends not to be. Instead there are more elegant concepts
like 'arrays' used to provide the equivalent functionality.
Overall, I find it hard to see that your two tasks really constitute the
best possible means of implementing list/set operations, although they
probably constitute the simplest means of extending the existing codebase to
do so. As such, if I had a problem today which needs such iteration, then I
would have no hesitation in pulling down Matthew's iteration package from
sourceforge. Or pointing someone else at to save them reinventing it.
But that does not mean that they should be pulled into the ant codebase,
because they would get in the way of a better soution. So, even if you and
Matthew do publish a pair of tasks on sourceforge which do iteration, I
would urge you to work with the rest of the ant-dev community to develop
that better solution.
-Steve
As an aside, from what I've heard of the ant changes made to get your
project work, with fallback build files in ant, and *DEFAULT* targets, it
scares me. Either you really are pushing the envelope as to what ant is
expected to do, or you've chosen a different path to achieve your goals from
the rest of us. I'd be interested to finding out more about it either
way -have you a snippet of the project post mortem on build process you
could pass on to cover not just the process but how the rest of the team
worked with it?
