So, only to put my opinion in vote terms:
+1 could break backward compatibility in release 2.0 if necessary:
We must change the API. There are so many to improve. We cannot be
plastered , specially now that commons math is still far from a stable
API. But I agree with backward compatibility directions anyway.
+1 to create a most abstract interface like:
interface InterfaceFoo2 extends InterfaceFoo1
The reasons I�ve already posted in last mail.;)
Mark Diggory wrote:
Simon Kitching wrote:
On Mon, 2005-06-13 at 14:47 +1200, Simon Kitching wrote:
Hi Mark,
In the example below, I would regard this change as being an
incompatible change anyway. Code using the new API isn't compatible
with
code implementing the old API because an exception can be thrown when
invoking a normal-looking method. Maybe if the new method's javadoc
explicitly states that "some implementations may not support this
operation and will throw an exception" but even then it feels wrong to
me.
Well, its not elegant, the exception handling establishes that there
is a forwards compatibility issue with the third parties
implementation (which they would then have to correct). Ultimately,
either way the third party needs to make the modification, the Stub
just delays this fact. Which is better, break during compilation, or
break during runtime? This shows a downfall in the strategy, a break
during compilation is more likely to be caught by the third party
developers and an exception is more likely to be caught by the third
parties "users". It'd seem better if the incompatibility were caught
by the developers, so in this way my example sucks. The simplest case
ends up the best. Just modify the Interface directly (yes, on a Major
release version) and let the third party developers adapt, thats
software evolution.
There are some cases where this pattern does work, though.
Commons-digester declares Rule as an abstract class rather than an
interface. This allowed the begin/body/end methods to be enhanced with
additional parameters, with the new methods delegating back to the old
ones by default. This pattern is also described in the eclipse doc
referenced by Stephen below. There isn't any interface involved,
though:
an abstract class is used *in place of* an interface.
In commons-digester 2.x (nowhere near release yet), Action is an
interface whose javadoc declares explicitly that it may change in minor
releases, and that users should subclass AbstractAction instead:
http://svn.apache.org/repos/asf/jakarta/commons/proper/digester/branches/digester2/src/java/org/apache/commons/digester2/
I should note that the reason that digester2 adopted the "interface +
abstract implementation" rather than the digester1 "abstract class
instead of interface" approach was that people pointed out:
* interfaces are useful for generating dynamic proxies at runtime.
* mock objects for unit testing are easier done on interfaces
Neither of these have problems associated with evolving the interface;
the dynamic problem of course isn't relevant and the unit tests can
assume to be only internal to the project and can be updated to match
the new release.
And where 99% of user code is simply *using* the API instead of
*implementing* the API, they can deal with the nice and traditional
interface. Only implementers of the API really need to care about the
existence of the abstract class.
Not only this but that 1% actually implementing the API is more than
likely going to be lurking on your developer list and contributing to
its development ;-)
IMHO, our current userbase is simply just using the API at this point
and will tolerate interface changes if it improves the API, it would
be an interesting poll to see if anyone actually implemented their own
Matrix classes on our interfaces and I'd be extremely surprised if it
had.
-Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
