ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik Hatcher" <>
Subject Re: [Bug 7482] - PatternSet.setIncludes() does not SET includes, but appends them to a list
Date Tue, 26 Mar 2002 19:31:33 GMT
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.
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.

At least thats my view of Ant 1.x tasks.  Thats why I emphasize "refactor"
when you come up with the subclass issues. And Dominique is right in line
with my thinking of containment rather than inheritance if you are to reuse
a task directly.

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


----- Original Message -----
From: "stephan beal" <>
To: "Ant Developers List" <>
Sent: Tuesday, March 26, 2002 2:05 PM
Subject: Re: [Bug 7482] - PatternSet.setIncludes() does not SET includes,
but appends them to a list

> On Tuesday 26 March 2002 19:26 pm, Dominique Devienne wrote:
> > Then how about using Containment instead of Inheritance? That way, you
> > create a brand new instance of the Task you delegate to, and initialize
> > to your heart's desire.
> Absolutely, it's just a lot of extra work ;). In fact, that's currently
> only way to do it without making changes to any class other than mine.
> > Of course, it's more typing to you, if you want to
> > expose setters/adders/creaters of the contained task. And you need your
> > execute() method... I'm assuming it's easy to create the task
> i'm overriding execute(), but not having getters to work with is a
> i've run into several times in trying to make use of Task objects. They
> not very subclassable, but this is apparently by-design. The lack of
> makes the objects difficult or impossible to use via delagation in some
> cases, and makes subclassing them a hassle because one must override the
> setter if he needs access to one of the not-yet-accessible data members:
> public void setFoo( boolean foo ) { = foo; super.setFoo( foo ); }
> (And then i supply a getter, since the poor bastard using the object next
> time might be me.)
> This overriding of setters is Not a Good Idea (let's even call it a Very
> Idea), because we cannot be guaranteed that the object passed to us
> is the actual object used by super.setFoo(). Perhaps it makes a copy and
> manipulates it in some way? Perhaps it sets it's value directly,
> which makes our copy out-of-sync (for primitive types, anyway)? It's
> dangerous, but only because the ant classes always reference their data
> directly - accessing even internal data ONLY via get/set methods makes all
> the difference in the world when subclassing. It solves a number of
> at the relatively small expense of another function call.
> > programmatically, which I don't see why it shouldn't be given all the
> > reflection ANT is doing (and my experience hasking ANT 1.3 back then).
> > FWIW, --DD
> That's an excellent point - why hide the data if Java will give it to you,
> long as you ask nicely? ;)
> ----- 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: <>

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

View raw message