ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: PATCH: Attributes of Target can reference properties
Date Tue, 03 Jul 2001 17:25:08 GMT
On Wed,  4 Jul 2001 01:42, Peter Vogel wrote:
> Yes, but with an extra layer of baggage that isn't necessary.  What I'm
> saying
> is that I don't understand your opposition to extending the base ant in
> ways that *reduce* the complexity of ant.  

It will only lead to reduction in complexity in short term. Look at the 
evolution of any feature of ant and you will see a pattern. My fav saying for 
this is "The path to perl is paved with good intentions". Eventually little 
by little extra features will be added or need to be added (ie recursive 
property resolution is a must if we use foreach or full mutability and 
delayed proeprty interpretation or partial resolution of datatypes).

Look throughout computer history and you will see that almost always this 
leads to certain difficult to maintain scenarios. It is far better to layer 
complexity (regardless of what software system). GUIs research since mid-90s 
is even starting to recognize this (and they tend to be last to the gate). 
Even in apache in other projects I have witnessed same conversations (early 
Velocity lists, Cocoon/XSP lists and prolly JSP lists - though I have never 
looked at them). 

> I've posted before about foreach
> -- how
> it would *reduce* the complexity of ant by eliminating a bunch of "task
> clones"
> whose only difference from their genetic donor is that they loop across a
> fileset.
> While filesets would be a common list to loop across, they are not the only
> one, so
> you strangle functionality *and* increase complexity by adding a bunch of
> tasks
> that are really just another task with fileset looping.  If is much the
> same sort
> of thing.  

> Instead of a nice clean:
>    <target name="whatever">
> 	<if expr="! ${buildnum}">
>             <!-- do what it takes to look up and update the buildnum -->
>       </if>
>       ...

BuildID should be a task not some adhoc scripting. It is generic enough to be 
a task - just that no one has ever sent in a patch to include it IIRC.

> Adding a target that has to be explained to people for no reason other than
> to work around the need for an if!

thats not a good example because the "ant" way saids there should be a task 
for that and thus no if. Complexity is pushed into task.

> I already posted the mess that results from hacking around the lack of a
> foreach.

yep I agree and I don't think anyone on ant-dev has denied it. But what is 
your point? 

> > *-----------------------------------------------------*
> >
> > | "Faced with the choice between changing one's mind, |
> > | and proving that there is no need to do so - almost |
> > | everyone gets busy on the proof."                   |
> > |              - John Kenneth Galbraith               |
> >
> > *-----------------------------------------------------*
> I think you and I both ought to take the above to heart!  I've actually
> spent quite a lot of time over the past two months working to instill the
> "ant way" into myself, and I'll admit my position has changed on a few
> topics, but not the ones I'm most vocal about here, because there *isn't*
> another way to do the things that need to be done that remains within the
> goals of ant.

My opinions have changed at least 3 times that I recall ;) In the begining I 
was of "traditional" ant mindset. ie procedural elements/scripting == evil. 
Then I went to dynamic templating+scripting is good with low cost antcalls as 
methods etc. Now I am in dynamic templating is bad, build specification 
should be deterministic and determined before build process. As procedural 
elements are always going to be needed this implies templating (or something 
else I haven't thought of).



| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |

View raw message