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 21:11:11 GMT
----- Original Message -----

> > That functionality, if desired elsewhere, should be refactored out into
> > other abstractions that can be reused by both the task itself and
whatever
> > custom stuff you want to do.
>
> i agree completely, but abstractions are generally made specifically to
> subclass ;).

Uh, you're talking yourself into a corner here buddy!  But I'll let you
continue arguing this if you like - these messages are permanently archived.

> > At least thats my view of Ant 1.x tasks.  Thats why I emphasize
"refactor"
> > when you come up with the subclass issues.
>
> Okay, but are you saying:
> a) refactor the original to take on that behaviour.
> b) refactor the original to make the behaviour more-implementable in a
> subclass or delegator?
> c) something different?
> d) -1! ;)

Well, it depends on what we're talking about specifically.  I think you can
get PatternSet to do what you want, you just have to do it a different way -
only call one of the methods and you get the 'set' functionality you want
(again, encapsulate, don't extend in this case).  If we're talking
subclassing actual Ant tasks - my vote is to refactor the functionality out
into standalone code that can be reused by the task.

> > And Dominique is right in line
> > with my thinking of containment rather than inheritance if you are to
reuse
> > a task directly.
>
> And i have No Problem with using containment, but in my case even
containment
> wouldn't work without refactoring the class i was containing (PatternSet).

Wrong, it would work - PatternSet can 'set' patterns - and yes it appends,
but only set once and you've got your 'set' capability!  See?

> don't at all mind doing that refactoring, but i need to clear it with the
dev
> team before i do it (unless i want to spend my time re-patching my local
copy
> on each ant update).

Agreed - and we appreciate such discussions.

> > So, that being said - I think we'll just make all our future tasks
'final'
> > - that'll learn ya!
>
> Ouch!
> OUCH! No.... (though i'd STILL try delegation/containment ;)
> And you'd have to completely refactor MatchingTask, then Zip, and then
> possibly the other 24(!!!!) classes which extend from MatchingTask. i
count
> 25 subclasses for that one (1.4.1 API docs). Maybe we re-think how
> MatchingTask could be used via delegation instead of having every 3rd core
> Task subclassing it?

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



--
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