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