commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Sterijevski <gsterijev...@gmail.com>
Subject Re: [math] Refactoring multiple regression classes
Date Thu, 14 Jul 2011 04:53:00 GMT
I was not aware of the versioning document. Thank you. A few more things
make sense now. It is still a bit bittersweet. In my opinion the interface
is a programmer's most terrific tool. It keeps him honest as well. I
understand your point though.

-Greg

On Wed, Jul 13, 2011 at 11:42 PM, Phil Steitz <phil.steitz@gmail.com> wrote:

> 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
> releases.
>
> Phil
>
> [1] http://commons.apache.org/releases/versioning.html
> >
> > Thanks,
> >
> > -Greg
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message