Please don't take my questions as criticism... I asked them "because" Lucene is held up as an example of good OO design, and I was trying to reconcile my knowledge of OO design with the Lucene developers.
Please don't take my response as overly-sensitive. Rather I was trying to re-focus things on functional issues, rather than style issues.
It just "feels like" IndexReader and IndexWriter should be interfaces.
I agree. The change would not be difficult to make, but it would be incompatible, and should thus not be done lightly.
It could be done compatibly as follows: add two new interfaces, IndexReadable and IndexWriteable. Have IndexReader and IndexWriter implement these interfaces. Then replace most references to IndexReader and IndexWriter with references to the interfaces. This is not as pretty as the incompatible way.
It seems like IndexReader should be an interface, with AbstractIndexReader providing some helper methods (potentially), and DirectoryIndexReader providing the concrete path/directory related methods. Alternatively, a AbstractIndex which implemented both, and then DirectoryIndex as the concreate implementation - since the index reading and writing are so coupled (in format). Then you could have CompoundDirectoryIndex, etc. ...
Right. That's the incompatible way. That needs to wait for Lucene 2.0.
As for the why my 'Filter' interface would make the world a better place... there may be cases where the filter is rather sparse, but the document set is quite large. The requirement to return a BitSet is a lot of overhead for a large document set - when a an alternative direct filter (for example, look up a document in the db, check some value, exclude document), would be far more efficient.
Good points. When Lucene was first written the bit-vector-based API was substantially faster. Calls to interface methods were much slower than non-interface methods, and the bit-vector call inlined. But JVMs have improved, so that the per-document interface call would not only be cleaner but probably not make a substantial performance difference. Another 2.0 feature!
Cheers,
Doug
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
