When I get a chance to come back to this, I'm strongly leaning towards leaving the ChangeLogTask as is, and starting off fresh with a new CvsChangeLogTask, which extends AbstractCvsTask. This will allow for any subclassing/delegation of the existing task to run unaffected, and allow for an approach to the date/time parameters that does not depend on a deprecatated API.
If this is not an acceptable strategy, I'd like to know why and what would be the preferred approach.
Thanks for your time and attention.
Ken
At 10:05 2003-02-26, Stefan Bodewig wrote:
On Fri, 21 Feb 2003, Ken Gentle <[EMAIL PROTECTED]> wrote:
> The justification for the new parameters is maintaining the > interface for any extensions of the ChangeLogTask. I don't think > the class is very amenable to subclassing (all the interesting > methods and attributes are private), and continuing to depend on the > IntrospectionHelper's use of a deprecated API seems risky.
Not only subclassing but delegation as well.
We once changed Available's setFile method to take a String argument instead of a File argument. Gump told us that something inside Castor's build (IIRC) created an Available instance and called setFile(File) on it.
What we've learned by that is that we can never be sure that nobody uses our public API.
I'm rather leaning towards separate attributes and preserving the old signatures as well.
Stefan
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
============================================================= J. Kenneth Gentle (Ken) | Phone: (610) 255-0361 Gentle Software, LLC | Email: [EMAIL PROTECTED] =============================================================
