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.
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, though.
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.
/LS
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
