On Sat, Mar 21, 2009, Michael McCandless wrote about "Re: Is TopDocCollector's
collect() implementation correct?":
>
> I think I'd lean towards a third solution: tighten up
> TopScoreDocCollector (make it final, remove ability to change its PQ,
> make things private) and have it focus on high performance collection
> by score.
The problem I see is this: TopDocCollector currently does not implement
any sort of interface for reading its output. This means that if you create
a completely different class implementing, for example, a different
sorting criteria (e.g., sort by date), there will be no base class or
interface that you could use for both of them, to allow changing the sort
criterion easily at run time. On the other hand, with the existing collector,
you can subclass TopDocCollector, and use that as the common base class.
If we're already creating a new TopScoreDocCollector (when was it added?
I must have been dozing off while this happened...) perhaps we can create
a read interface for it (with the getTotalHits() and topDocs() methods), and
have this class implement that interface? Then, indeed, nobody will have
any reason to extend the TopScoreDocCollector class, and it can be final.
--
Nadav Har'El | Sunday, Mar 22 2009, 26 Adar 5769
IBM Haifa Research Lab |-----------------------------------------
|"Did you sleep well?" "No, I made a
http://nadav.harel.org.il |couple of mistakes."
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
