Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 91475 invoked from network); 26 Mar 2002 22:25:24 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 26 Mar 2002 22:25:24 -0000 Received: (qmail 28556 invoked by uid 97); 26 Mar 2002 22:25:27 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 28521 invoked by uid 97); 26 Mar 2002 22:25:26 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 28510 invoked from network); 26 Mar 2002 22:25:26 -0000 Message-Id: <200203262225.g2QMPON27289@mail008.syd.optusnet.com.au> Content-Type: text/plain; charset="iso-8859-1" From: Darrell DeBoer To: "Ant Developers List" Subject: Re: [Bug 7482] - PatternSet.setIncludes() does not SET includes, but appends them to a list Date: Wed, 27 Mar 2002 18:25:07 +1000 X-Mailer: KMail [version 1.3.2] References: <98D21B073202584C9125C860580DC4ED0F4F0E@lgchexch006.ad.lgc.com> <001d01c1d50a$c225f020$6501a8c0@darden.virginia.edu> In-Reply-To: <001d01c1d50a$c225f020$6501a8c0@darden.virginia.edu> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Wed, 27 Mar 2002 07:11, Erik Hatcher wrote: > MatchingTask is abstract and would not be made final. �I got no problems > with abstract tasks! �:) > > We will not make any of the classes final that were in existence when Ant > 1.4.1 was released - it simply breaks backwards compatibility. > > There is nothing wrong with extending Task or MatchingTask - I am not > claiming that at all - they are designed to be extended. �Jar, however, is > not, at least not to the extent of adding features like you are doing. > Encapsulate - for the last time! �:) > > � � Erik Erik, I just want to say that I fully support your line of argument on this matter. Subclassing existing Ant tasks, (and even creating/executing programmatically) seems to cause the biggest headaches wrt backwards compatibility. When functionality needs to be shared between tasks, it's much better to refactor that functionality out into a separate, well-defined helper class to be used by both Tasks. A few other notes that I agree with you on. (or I'm just sprouting off ;) ) * I tend to always favour delegation over inheritance * Where I use inheritance, I prefer to pull common functionality into a common, abstract superclass, so that concrete classes aren't themselves extended. (abstract or final, you choose...) * I tend to use interfaces everywhere that I need polymorphism. This approach leads to a greater number of simpler classes, and I believe produces more maintainable, more extensible code. I'm guessing that many people disagree with this approach (I'm often distressed by the lack of interfaces in the Java APIs themselves), but it works for me. I just wanted to let you know that you're well supported in this discussion and if I was in the same timezone, I might even be able to provide real-time support. -- ciao, Daz -- To unsubscribe, e-mail: For additional commands, e-mail: