Hi, Beyond that, we should add final modifier to all methods that simply delegate to other methods from the same class. This is another trap when trying to be backwards compatible. An easy-to-use method that simply takes some defaults for specific parameters of a telescopic other one should always be final. If somebody subclasses, he can only overwrite the large extended telescope and don't need to take care of the easy-to-use methods. I revised lots of classes for that, but there are still some worse cases e.g. in IndexReader.
If we don't make such delegating methods final, we also have the same backwards compatibility problem like with tokenStream or FilteredIndexReader. This is just seen to be as an additional comments about stuff that easily goes wrong when making APIs. Make everything final that's not intended to be modified in subclasses (or make the whole class final). And most methods are not needed to be overridden, only open them up for subclassing when there is *really* a use case! We can remove final later easily, but initially we should prevent subclassing. This would remove lot's of VirtualMethod usages in 3.x (my abstraction of the TokenStream backwards layer). Uwe ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -----Original Message----- > From: Grant Ingersoll [mailto:gsing...@apache.org] > Sent: Monday, October 24, 2011 4:02 PM > To: dev@lucene.apache.org > Subject: Re: IndexableField(Type) interfaces, abstract classes and back compat. > > > On Oct 24, 2011, at 9:56 AM, Robert Muir wrote: > > > On Mon, Oct 24, 2011 at 9:52 AM, Grant Ingersoll <gsing...@apache.org> > wrote: > >> Hi, > >> > >> I was perusing trunk code on the way back from Eurocon and noticed the > new FieldType stuff has some interfaces in it. In the past we've tried to stick to > interfaces for only simple ones (i.e. one or two methods that aren't likely to > change at all) and instead used abstract classes for bigger classes that may be > subject to change more often. > > > > I think its good you brought this up Grant. > > > > I wanted to mention this: as far as interfaces versus abstract > > classes, in my opinion Lucene was under a false sense of security > > before thinking that abstract classes actually solve these back compat > > problems. > > In fact they can create serious problems like > > https://issues.apache.org/jira/browse/LUCENE-2828. In other words, if > > someone writes a delegator over an abstract class, its asking for > > trouble. > > On the other hand, delegators over interfaces are safe because they > > (and we) get a compile-time break for the new methods. > > Good point. Basically, going down this line, are we saying that we would still > allow new methods on minor versions on Interfaces? My personal take is that > if we do, we primarily just need to communicate it ahead of time. Ideally, at > least one release ahead, but maybe it is just an email. We just want to avoid > surprises for people where possible. > > -Grant > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional > commands, e-mail: dev-h...@lucene.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
