Ok I didn't phrase it well ... what I meant to say is I don't understand why you had to invent a new class MRHC instead of just coding that logic into HC, with an empty implementation like I suggest. I'm not saying this is something that should have been thought of, but that MRHC in and on itself does not do anything, besides declaring an abstract method. And since the Lucene code has moved internally to use MRHC, I think that my suggestion to pull that method up to HC w/ an empty implementation is a reasonable one, and it simplifies things a lot.
Because now, like Mike asked somewhere at the beginning of this thread, one does not know which collector to extend - HC or MRHC. The decisions is even tougher because I believe MRHC does not solve anything for the regular TopDocCollector (original) case? Meaning, isn't Lucene already iterating over the segments one by one? Isn't MRHC good mostly for TopFieldCollector? Don't get me wrong, I think that MRHC makes sense for someone who wants to write a HitCollector and take advantage of knowing when a reader changes / moving to a new segment. But asking everyone to choose between HC and MRHC is a bit too much IMO. If HC would have had this setNextReader() with empty implementation, all that someone had to choose from is whether to override that method or not. Now he needs to choose which HC implementation to extend, which is at the core of this thread's problems. On Wed, Mar 25, 2009 at 10:14 PM, Mark Miller <markrmil...@gmail.com> wrote: > bq. I personally don't understand why MRHC was invented in the first place. > > The evolution of MRHC is in the comments of LUCENE-1483 - a lot of comments > to wade through though. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: java-dev-h...@lucene.apache.org > >
