ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From stephan beal <>
Subject Re: [Bug 7482] - PatternSet.setIncludes() does not SET includes, but appends them to a list
Date Tue, 26 Mar 2002 20:05:27 GMT
On Tuesday 26 March 2002 20:31 pm, Erik Hatcher wrote:
> I think you need to get over the idea of reusing tasks so much.  I view the
> task class more as a "facade" to the underlying functionality it provides.

But 'reuse' is about #2 on the list of "why is OO valuable" - reuse. In the 
case which came up today, it's not even the Task which is the problem - it's 
PatternSet (okay, it's not A problem, it's a point of confusion and "lack of 
a feature which i want", which makes it My Problem). (Doc patch coming 
tonight, Erik, by the way.)

> 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 ;).

> 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! ;)

> 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). i 
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).

> So, that being said - I think we'll just make all our future tasks 'final'
> - that'll learn ya!

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?

----- stephan
Generic Unix Computer Guy -
Office: +49 (89)  552 92 862 Handy:  +49 (179) 211 97 67
"...control is a degree of inhibition, and a system which is perfectly
inhibited is completely frozen." -- Alan W. Watts

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message