On Tue, 2008-10-07 at 22:00 -0400, Grant Ingersoll wrote: > On Oct 6, 2008, at 7:06 PM, Ryan McKinley wrote: > >> > >> I like this one. Of course, my Lucene experience would argue that > >> interfaces are a royal pain when it comes to back-compatibility in > >> public, open source projects for all but single method interfaces, > >> where you never know where the next great idea is coming from... ;-) > >> > > > > It took me a while to understand the fear of interfaces -- you have > > to replace the things you learn about OO programming with a concern > > for back-compatibility. I get it now, but it seems a shame... > > > > I wouldn't call it fear, so much as pragmatism. Interfaces make a ton > of sense in a lot of situations, and I'm very pro Interfaces, but... ... > > I don't think early stage projects should worry too much about back- > compat. At least not until 1.0. > > > > How do other projects deal with back-compatibility with interfaces? > > > > Since this is a new project, we are in a position to define the > > contract for major/minor release compatibility. Perhaps every > > interface has a concrete/abstract implementation and we say > > something like "interfaces *may* add new functions between minor > > releases (they will not be removed) -- to protect your code for back- > > compatibility be sure to extend an concrete class rather then > > directly implement the interface. If you implement the interface > > directly, you may need to add functions in order to link to a new > > version." > > > > Interfaces make good sense in OO programming (and testing) - it > > seems a shame to lock things to an abstract super class. > > > > Perhaps my vision is blurred a bit by my use of Wicket and the > > automagic bean binding (via spring or whatever) -- using interfaces > > is nice because you know everything can be wrapped as a proxy -- > > with classes, you can run into funny proxy problems. > > > I agree.
Me too, that is why r702929 is a good way in between. Abstract implementation of interfaces are normally making constant integration way easier. The developer can decide when (s)he wants to implement a concrete functionality of their own robot. The "major/minor release" clause sounds swell. salu2 -- Thorsten Scherler thorsten.at.apache.org Open Source Java consulting, training and solutions --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
