On Thu, Mar 26, 2009 at 5:28 PM, Marvin Humphrey <mar...@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-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
