Ultimately, though, the decision to refactor the codebase to use interfaces more pervasively lies with Doug.
Actually the decision lies not with me, but with the Lucene PMC as a group, according to Apache's voting process:
http://www.apache.org/foundation/voting.html
But, like other PMC members, I do have veto power. Fortunately I've never had to use it. We've always come to agreement through reasoned argument.
In this particular case, I do not object to making interfaces for IndexReader and IndexWriter. What we need is a well-designed, back-compatible, fully-javadoc'd patch that implements this. Folks (including myself) may have reasonable objections to the first version. So it will take some patience and determination to make such a change to these core classes.
My guess at the best way to approach this is to add new interfaces (e.g., named IndexReadable and IndexWritable) and to then have IndexReader and IndexWriter implement these. That makes back-compatibility easier. Then one could add factories too. Someone proposed IndexReaderWriterFactory as a name. Why not just call this IndexFactory?
Finally, this change, on its own, is not a high-priority for me. Long term, I hope we can re-structure these APIs to make them extensible in more interesting ways. Consider point 11 in section 1.2 of http://wiki.apache.org/jakarta-lucene/Lucene2Whiteboard as an example. This sort of thing would probably best be implemented by decomposing IndexWriter and IndexReader into sets of interfaces. But until we do that I don't think I would make use of interfaces here. So if others would make good use of these interfaces, then the onus is on them to make the change.
Doug
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
