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.ste...@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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
