Thanks Hoss and Grant for links to all the background on this issue. I've read through them and now my brain is really fuzzy...
For 1219, I'd rather not introduce yet another interface into the Field classes. I think it confuses our users to have so many classes/interfaces to represent the fairly simple concept of "a field on a document", and adding another interface just adds to this grief. So I guess I'd take the current patch in 1219 over doing that. But I still don't really like the current patch either. I do like moving towards a separation of Document for indexing vs searching for 3.0. Disregarding for starters how we get there from here... Wouldn't we just want a base class (not an interface), say ReadOnlyField, that is used in documents retrieved by a reader? This class would also have Index.*, Store.*, TermVector.*, and isStored/Indexed/Tokenized/Compressed, etc, as these are recoverable from an index. Couldn't this be a concrete class, ie, the actual class instantiated when a Document is loaded from a reader? And then a subclass, IndexableField, that adds reader & tokenStream values, get/set boost, setters to change a field's value, etc. Then similarly two Document classes. Is this too simple for some reason? The only 2 classes that use AbstractField in core are FieldForMerge and LazyField. Couldn't these subclass from ReadOnlyField and override the few methods they need to? Mike Doug Cutting <[EMAIL PROTECTED]> wrote: > Chris Hostetter wrote: > > Committers tend to prefer abstract classes for extension points because it > > makes it easier to support backwards compatibility in the cases were we > > want to add methods to extendable APIs and the "default" behavior for > > these new methods is simple (or obvious delegation to existing methods) > > so that people who have writen custom impls can upgrade easily without > > needing to invest time in making changes. > > > Yes, this is a huge problem with interfaces. We struggle with it in > Hadoop, where interfaces were used extensively and keep us from > improving core APIs in much-needed ways. In the end we'll end up > replacing them with abstract classes in a new package. > > > > But abstract classes can be harder to mock when doing mock testing, and > > some developers would prefer interfaces that they can implement with > > their existing classes -- i suspect these people who would prefer > > interfaces are willing to invest the time to make changes to their impls > > when upgrading lucene if the interfaces were to change. > > > These problems seem more easily surmountable. It should be no harder to > implement a mock version of an abstract class than an interface. And > developers are not much burdened by being unable to use a single class > for many things. > > > > Perhaps the solution is a middle ground: altering our APIs such that all > > extension points we advertise have both an abstract base class as well as > > an interface and all methods that take them as arguments use the interface > > name. then we relax our backcompat commitments > > such that we garuntee between minor releases that the interfaces won't > > change unless the corrisponding abstract base class changes to acocunt > > for it ... so if customers subclass the base class their code will > > continue to work, but if they implement the interface directly ignoring > > the base class they are on their own to ensure their code compiles against > > future minor versions. > > > It will be hard to enforce this. Applications will implement the > interfaces and will be broken by changes to them and folks will > complain, generating lengthy, non-productive incompatibility flamewars. > > After 10 years of Java programming, I find that interfaces are rarely > worth the trouble they create. They're handy for single-method things > that never change, like Comparable, Runnable, and Cloneable, but for any > more complicated API that's part of an evolving system they're usually a > mistake. > > > Doug > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
