Simon Kitching wrote: [snip] > So the rule would be: > * the project provides both an interface and an abstract class that > implements that interface. > * code that *uses* the API should always use just the interface, ie > *call* methods via the interface and pass instances around as the > interface type > * code that *implements* the API should always subclass the base class. > > The project reserves the right to add methods to the interface, but will > always provide a concrete default implementation on the abstract > subclass. Methods will *not* be added to the interface if a sensible > default implementation cannot be provided. > > That sounds like a pretty good approach to me; seems to ensure maximum > backward compatibility while keeping a clean interface-based API (which > allows interface-based proxies to be generated at runtime). > > I would agree with Jörg here, that as long as release-notes document > expected clirr incompatibilities there is no problem. Clirr can of > course be configured to ignore specific classes when processing...
Exactly ... it's always nice to get a clean summary by a native speaker :) - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
