ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Hatcher <>
Subject Re: private to protected and extensibility of Ant
Date Sun, 15 Sep 2002 10:56:02 GMT
Leo Sutic wrote:
> Erik,
> thank you for your reply. I understand that Ant is developed as open 
> source, and I blame no one but my own inability involved and contribute 
> to Ant for the code breaking. The break was discovered when I figured 
> I'd try out Ant 1.5 on our build system, and the rollback to Ant 1.4 
> took about 10 seconds, so nothing was lost and it is no obstacle for me.

Fair enough.  Its just frustrating for us as Ant committers to push 
betas out and then a final release, and then even a .1 beta release and 
not get bug reports until everything is out the door.

Its more a general comment than anything directed to you - we just need 
to push folks more to try things earlier rather than later.  I realize 
this is difficult for most of us who are already swamped with our 
day-job work and plugging in a new, possibly fragile, tool could cause 
some problems, but luckily with Ant only one person would need to try it 
and verify that it worked ok without breaking an entire team of developers.

> 1) The taskdefs are not supposed to be extended by users. I would argue 
> that they should be. Ant is supposed to be extended by users writing 
> their own tasks, and using the existing tasks as base classes is, in my 
> opinion, a natural first step. I agree that the Ant kernel is off-limits 
> to users, though.

I take some issue with this.  The classes corresponding with the 
<taskdef> are not what I'd consider something folks should extend, 
generally speaking.  I feel these classes should be more of a facade or 
wrapper over underlying API that is to be designed for reusability. 
Does that make sense?  For example, the <exec> task uses a more 
generalized API under the cover to execute native programs.  So, rather 
than extending ExecTask, make your own task and use Execute under the 
covers to do the work.

In a different manner, SQLExec extends JDBCTask, which is a generalized 
abstract task to take in all the attributes/elements necessary to set up 
a SQL connection allowing subclasses to provide the specific stuff.   I 
would argue in JDBCTask that methods like setClasspath should have been 
final so that subclasses could not affect the framework that JDBCTask is 
providing.  Your thoughts on this?

I would also say that JDBCTask should have taken final control over 
execute and proxied to another new abstract method that subclasses would 
be required to implement.  And I did not think this through when I saw 
the JDBCTask stuff come through, so I apologize, but what I've just 
stated is how I implement things in my day job and how I think 
subclassing/encapsulation should work with Ant.

> 2) Things should start out locked down and get opened up as required. My 
> experience is that if a class starts out not being designed for 
> subclassing, the "opening up" process becomes very ad-hoc, and is more 
> dangerous than to design the class for extensibility up front. Consider 
> a class wihere some code from a large method is broken out as a private 
> method. The contract for the private method may at first be quite loose, 
> and only against the previously big method:

Certainly your concerns are quite valid here, but its more up to all of 
us to keep one another in check and ensure that such "opening up" 
refactorings are done wisely and that previously private methods are not 
simply turned into public methods, but wisely refactored properly.

I do not disagree that we should design for subclassing in many 
situations, but I'd also put forth that subclassing is but one (perhaps 
inferior?) way to do object-oriented programming.  Encapsulation and the 
use of interfaces is more to my tastes these days, leaving subclassing 
as the last option considered.

> My experience is that the resulting contract tends to be very ad-hoc, 
> and that the proliferation of ad-hoc contracts pose a greater danger to 
> program robustness/developer sanity/system security than to express your 
> intent regarding how the class should be extended with protected and 
> public methods from the start. After all, why mark a method as private 
> if you intend it to be overridden at some time? Why not mark it 
> protected and be done with it? If you intend for it to be overridden at 
> some point you can't assume it isn't overridden *now* - unless you want 
> to go back and change all your code when it does become overridden.

Again, I'm not advocating making all methods private and then in a time 
of subclassing need simply change one to public.  But having everything 
public or protected makes a *contract* that we must adhere to, so things 
that are not private need to be thought through much more seriously than 
private ones.  Starting with private allows you time to think through 
issues and wait until a need arises (which is what agile programmers do, 
and I consider myself among them).  But agile development does NOT 
advocate taking shortcuts or doing things like turning a private method 
public without considering it and *refactoring*.


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

View raw message