> -----Original Message----- > From: James Duncan Davidson [mailto:[EMAIL PROTECTED]
> 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 sense. > 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? jim
