I really liked HItCollector and hate to give up the name ... However Collector is fine with me either, and it is at least more generic than HitCollector ...
Hitable sounds too aggressive/violent to me :) BTW, I guess I should create some new searcher API which receives this Collector class (is Collector the chosen name?) and deprecate those who accept HitCollector? Those can also skip the instanceof check, and wrapping of HC to MRHC ... That also means that I should throw that MRHC wrapper (which rebases doc Ids)? If HitCollector is deprecated, then there's no need to keep it. But perhaps we want it there in 2.9 for easier migration? Personally I think it's redundant since in 3.0 people will need to change all their collectors anyway (since HitCollector will be removed, and every class which extends HitCollector will need be modified). What do you think? Also, there's no need to deprecate MRHC, since it's only in the trunk - I can simply rename it, right? Ok I'll go ahead and prepare a patch. We can discuss the name more, at the end it will just be a short "refactor" action in Eclipse, so that shouldn't hold us (or me) up. Shai On Fri, Mar 27, 2009 at 1:24 AM, Earwin Burrfoot <ear...@gmail.com> wrote: > > 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?). > That's exactly what I'm using in my app -> abstract class Collector > extends HitCollector, that serves as a base for all my custom > collectors :) > So, yeah, I like this name. > > > Yeah I'm not really a fan of Listener either. > +1 > > -- > Kirill Zakharenko/Кирилл Захаренко (ear...@gmail.com) > Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423 > ICQ: 104465785 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > >
