----- 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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
