ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <co...@cortexebusiness.com.au>
Subject RE: Ant q? about core Java task: why are members private?
Date Tue, 27 Mar 2001 23:38:54 GMT


> -----Original Message-----
> From: Peter Donald [mailto:donaldp@apache.org]
> Sent: Wednesday, 28 March 2001 9:13 AM
> To: ant-dev@jakarta.apache.org
> Cc: ant-dev@jakarta.apache.org
> Subject: Re: Ant q? about core Java task: why are members private?
>
>
> At 03:01  27/3/01 -0500, Shane_Curcuru@lotus.com wrote:
> ><Apologies in advance if this was an obvious question about Ant 1.3>
> >
> >I'm starting to implement an optional task to execute basic operations on
> >other Java objects and my first thought was to simply extend the existing
> >Java task, since it already has a bunch of functionality I need
> (classpath
> >handling, basic forking, etc.).  But all the member variables there are
> >private, making them inacessible to subclasses; hence I'm out of luck.
> >
> >A quick review of some other core taskdefs shows that some tasks declare
> >everything private, some protected, and I can't figure out a particular
> >difference between which kinds of tasks are which.  Why the difference?
> >And why not use protected as the default for most classes?  (if you don't
> >want people subclassing, then just declare yourself final, I'd think).
>
> I would be happy to make them protected if you send the patches ;) Be
> warned though that they are volatile and could change between ant
> versions.
>
> Another option is instead of reusing you actually manipulate a contained
> task. This is much safer but can be extra work.
>

A couple of points.

I am generally against having data members as protected. It means weaker
encapsulation, which allows subclasses to violate the super class' call
invariant. It also increases the size of the contract between the class and
any subclasses. That contract should be restricted to methods, IMHO.

I am also concerned about creating a larger contract from Ant's core to task
developers. To make backward compatability easier, we should have a fairly
narrow contract to task writers. Rather than extending core Tasks or even
using project.createTask to have an embedded task, we should be providing
the services in the Ant core that are available to Task writers to perform
certain common operations.

For example to execute java code, Ant currently provides the ExecuteJava
class.

Thoughts?
Conor


Mime
View raw message