+1, this makes total sense! Mike McCandless
http://blog.mikemccandless.com On Thu, Nov 1, 2012 at 5:04 PM, Robert Muir <[email protected]> wrote: > On Thu, Nov 1, 2012 at 4:55 PM, Uwe Schindler <[email protected]> wrote: >> +1, I think PostingsEnum ist he much better idea! I was thinking about that >> several times. In fact DocsEnum is just a specialized DocIdSetIterator, so I >> never understood the difference in the early Lucene 4 days. Now we have some >> extra methods, but most of them are optional and a PostingsEnum extends >> DocIdSetIterator (I would like to have *implements* more...) is perfectly >> fine for all those use cases. And as both Scorer and PostingsEnum extend the >> same base class, this makes code reuseable and looking identical in lots of >> cases (like simple Filters). A filter for a Term could directly return the >> PostingsEnum for this term in getDocIdSet()... >> > > I was frustrated with some of the same things as simon, and thought > about the 'implements' too. (i actually went so far as to make a quick > prototype patch to see what it look like: > http://pastebin.com/vum1mx9H). I don't like that if you write a codec, > you must write duplicate enums and cannot have e.g. your positional > enum extend your docs one and so forth. > > I also think it limits us for the Scorer case (it extends DocsEnum > now, but what if you wanted a Scorer where you could walk its > positions...) > > But anyway I think I like Simon's idea (we can deal with the interface > idea separately). > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
