commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [math] Refactoring multiple regression classes
Date Thu, 14 Jul 2011 04:42:40 GMT
On 7/13/11 9:05 PM, Greg Sterijevski wrote:
> Phil,
> "Fortunately for users, maybe less fortunately for developers, we
> can't really "evolve" our API rapidly ....  This is why we
> favor abstract classes over interfaces."
> Just so that I am sure I understand, let me restate the objection to an
> interface. An interface approach is more likely to be used broadly, so any
> changes which might be made would have a disproportionately large impact. Is
> this correct?

No, our rule is we make incompatible changes only in major
releases.  See [1].  Changes to interfaces are incompatible changes,
so whatever interfaces we define we have to be prepared to live with
until the next major release.  We have no way of telling who is
using what or how, so our rules are expressed simply in terms of
source and binary compatibility.  Abstract classes can add
(non-abstract) methods without breaking compatibility.  That is why
we favor them where possible over interfaces.
> Isn't this a bit of a punt? On the surface the user gets a guarantee, but
> the guarantee is a deadend. If we decide a different approach is warranted,
> the object is deprecated and ditched at some point. More importantly, if it
> is a successful interface isn't that a good thing?
>  If it makes its way into
> a lot of other code, then I doubt we will need to make many changes. Also, I
> foresee a two track evolution of features. The interface defines the basic,
> most limited set of functionality. Everything else is throw into abstract
> and concrete implementations. When a functionality seems to exist in most
> derived classes, then the debate should commence about its inclusion in the
> regression interface. The evolution would most likely be new features in, as
> opposed to current features cut out. There would be a lag of probably a year
> in moving a new feature up the inheritance structure to the interface. Maybe
> your experience is different. I could be wrong about user demands...

What it comes down to is being certain that the core material that
we put into the interface is not going to change.  Our experience in
Commons has been that that is often very hard to do and in most
cases abstract classes will serve the same purpose without imposing
the same kind of constraints.   The evolution you describe above is
natural and bound to happen.  Trying to avoid interfaces gives us
more flexibility in timing, enabling innovative change between major


> Thanks,
> -Greg

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message