: That would require a user to subclass both IndexWriter and Searcher. I was assuming there would be corrisponding setters and that Searcher and IndexWriter would maintain Maps, but that wouldn't really help in cases of dynamicly named fields ... you would certinaly want some sort of Factory (or "SimilaritySelector" like FieldSelector) so you can plugin custom behavior.
: Since Similarity is already passed around, adding a factory method : their seems like the easiest approach. It's also a class, so we could : easily add a method. Searcher and IndexWriter are classes too, so it's just as easy to add setters and getters for a new SimilarityFactory on each of them as it is to retrofit Similarity into being a factory for itself ... and it would seem less confusing. Compatibility could even be maintained by making the current setSimilarity method create a SimpleSimilarityFactory that allways returns the same Similarity. The getSimilarity() methods on both classes could delegate to the factory, newer more complex Queries can use searcher.getSimilarityFactory().getSimilarity(complexCriteria) : An optional Query param or other context (or more than one factory : method) was just a quick idea... may or may not ultimately make sense. More then one method on the factory would be great ... but all the more reason to create a ne class instead of adding a lot of new factory methods on teh existing Similarity API. : It might be a little cleaner to pass around a SimilarityFactory, but : that ship has sailed IMO (along with many others :-) It's not too late ... it seems really straightforward to me (but talk is cheap -- i haven't actually sat down and thought of potential uses cases and how well they would work with this type of approach). -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
