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 19:05:28 GMT
On Tuesday 26 March 2002 19:26 pm, Dominique Devienne wrote:
> Then how about using Containment instead of Inheritance? That way, you can
> create a brand new instance of the Task you delegate to, and initialize it
> to your heart's desire. 

Absolutely, it's just a lot of extra work ;). In fact, that's currently the 
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 own
> 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 limitation 
i've run into several times in trying to make use of Task objects. They are 
not very subclassable, but this is apparently by-design. The lack of getters 
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 Bad 
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, internally, 
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 problems 
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, so 
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: <>

View raw message