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 just think "ResultsCollector" is less euphonic and zippy than "HitCollector", so it's worth exploring alternatives. > How about dropping the word Collector, since it might not collect anything, > and just save the highest score, or compute some facets .. Sure, wiping the slate clean and re-examining HitCollector's actual purpose and usage to discover new names is a good approach. Similar thinking went into "Hitable" and "Harvester". FWIW, I'd have to disagree that HitCollector doesn't collect anything. It may not collect "hits" per se, but it's definitely iterating over "hits" (in the sense of "successful matches") and with only rare exceptions, it's collecting *something*. > 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. Cheers, Marvin Humphrey --------------------------------------------------------------------- To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
