lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <luc...@mikemccandless.com>
Subject Re: Is TopDocCollector's collect() implementation correct?
Date Thu, 26 Mar 2009 22:03:07 GMT
On Thu, Mar 26, 2009 at 5:28 PM, Marvin Humphrey <marvin@rectangular.com> wrote:
> On Thu, Mar 26, 2009 at 04:01:26PM +0200, Shai Erera wrote:
>> I still think that ResultsCollector does what you describe. It simply
>> collects results, while the word 'result' is quite *open* and does not
>> commit to anything ...
>
> Another advantage of "ResultsCollector" is that the name suggests good
> self-documenting subclass names and variable names.  For instance, it's
> reasonably clear what a "BitSetCollector" or a "TopDocsCollector" might do.
> And when there's only one var around, the name "collector" is an obvious
> choice no matter what the class.  This is all possible because there's no
> other use of "Collector" within Lucene.

I think ResultsCollector (or maybe ResultCollector) is my favorite so far...

But how about simply Collector?  (I realize it's very generic... but
we don't collect anything else in Lucene?).

>> What about something with a *Listener like: DocIdListener, SearchListener,
>> MatchListener (it listens on search matches).
>
> Considering how we attach HITCOLLECTORTHINGY onto the matching process is a
> novel take and clarifying to see.  However, maybe it's just me, but *Listener
> evokes the JavaScript EventListener stuff, which seems radically different.
> Also, if I saw a "listener" variable in scoring loop code, or a
> "TopDocsListener" module in the JavaDocs, it wouldn't spring out to me that it
> would be doing what a HitCollector does right now.

Yeah I'm not really a fan of Listener either.

Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message