lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug Cutting <>
Subject Re: incorrect OO in lucene source?
Date Tue, 20 Apr 2004 18:10:40 GMT
Robert Engels wrote:
> 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!



To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message