commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Sterijevski <>
Subject Re: [math] Refactoring multiple regression classes
Date Thu, 14 Jul 2011 04:05:13 GMT

"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?

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...



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