ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Leo Sutic <>
Subject Re: private to protected and extensibility of Ant
Date Sat, 14 Sep 2002 23:16:27 GMT

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.

I intend for my next argument in this discussion to be in the form of a 
patch, but first let me address two of the points you raise:

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, 

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:

   public bigMethod () {
     ... lots of stuff ...

gets refactored into:

   private smallMethod () {

   public bigMethod () {
     ... less stuff ...
      smallmethod ();
      ... less stuff ...

or something similar. The point is that we have a private method that 
doesn't have a very solid contract against the rest of the class, as the 
programmer did not think it neccessary due to the method being private and 
thus not being used from any other place except the class it is defined in. 
However, if some evolutionary pressure would force the previously private 
method to become protected, a well-defined contract has to be made for it. 
After all, it may now be overridden in subclasses.

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.


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

View raw message