ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Cook" <>
Subject RE: Did somebody say Shut up and Write? :)
Date Wed, 20 Dec 2000 22:09:21 GMT
> -----Original Message-----
> From: James Duncan Davidson []

> I have. You state that the one of the reasons for treating everything as a
> task is for efficiency. And you note that Ant spends cycles analyzing the
> dependencies between targets. I think you over stress the impact
> of these on
> performance. In fact, in a typical build of even a small project
> of 10 or so
> class files -- Ant spends so little of its time in the setup necessary to
> assemble the project tree *and* analyze dependencies that this is
> not worth
> optimizing out. Almost all time is spent in the compiler or in other tasks
> -- the impact of which is beyond the control of the core.

I didn't note that "Ant spends cycles analyzing the dependencies between
targets" and when I mentioned anything about efficiency, I am *not*
referring to execution performance, but rather clean and simple code.

> As interesting as it is to view the world as a tree of single type nodes,
> when you get into using things for long its inevitable that some sort of
> specialization creeps in somewhere. And its actually quite useful
> at times.
> Genericity is not necessarily your friend. Yes, this is a biased
> opinion --
> it's based on 3 1/2 years of coding Java at JavaSoft though if that means
> anything.

Hmmm...only 3 1/2 years? Anyway, I think the code speaks for itself. I have
no problem with specialization, however it should be layered on top of a
stable generalized core. That is what my proposal advocates, and I have not
read anything that would dissuade me from this design. It definitely makes

> Also, as appealing as it is to say that all things should implement
> interfaces -- it doesn't always work out so well in practice. I've been a
> heavy proponent of interfaces everywhere in the past. And a
> strong detractor
> of inheritance no matter how shallow. However, after working that
> way for a
> few years, I've found that there are a few problems with this.

I agree that interfaces are an appealing design choice, and I strongly
disagree that it "doesn't always work out so well in practice". I suppose it
doesn't *always* work out so well when you try to design interfaces at too
high a level. Look at the List or Collection interfaces in the Java
Collections class. They are perfect examples of interfaces defined at the
right level.

> Once you code
> an interface, you should *not* touch it. It's a published thing
> that, if you
> change it, breaks other things in subtle and nasty ways.

Welcome to one of the commandments of object-oriented programming. Thou
shalt not change interfaces. This doesn't preclude you from extending
interfaces and/or augmenting methods to an already-defined interface. Hence
the need to define interfaces at the "appropriate" level.

> Also, in *so* many
> cases that I've used interfaces in to allow all sorts of implementations
> behind -- I've found that there have been 1, maybe 2 implementations of
> those interfaces. And for that you pay in extra code, extra class
> load time,
> etc.

I can't believe that I am debating the merits of the interface design
pattern with someone who has spent the last 3 years developing APIs that are
essentially based on the same pattern.

> That's not to say that interfaces are bad either -- they have their place.
> And that place is in very specifically defined long lasting
> unchanging code
> where there are going to be *lots* of implementations. I'm talking about
> things like JDBC, JAXP, Servlets, etc. And even there -- you'll see that
> there are actually quite a few abstract classes instead because there is
> functionality that needs to be there of some sort.

I agree with you that interfaces are good (or not bad as you put it). The
examples that you cite are APIs, although those APIs do leverage the
interface design pattern very well. So, tell me again, why shouldn't Ant
*core* be based upon the same common strengths that the interface pattern
gives all of these other rock-solid APIs?


View raw message