ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher" <jakarta-...@ehatchersolutions.com>
Subject Re: [Bug 7482] - PatternSet.setIncludes() does not SET includes, but appends them to a list
Date Tue, 26 Mar 2002 22:34:27 GMT
Thank you Darrell!  Just glad that I'm "getting it"!  :)

    Erik


----- Original Message -----
From: "Darrell DeBoer" <darrell@apache.org>
To: "Ant Developers List" <ant-dev@jakarta.apache.org>
Sent: Wednesday, March 27, 2002 3:25 AM
Subject: Re: [Bug 7482] - PatternSet.setIncludes() does not SET includes,
but appends them to a list


> 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:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message