+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()...
Uwe ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -----Original Message----- > From: Simon Willnauer [mailto:simon.willna...@gmail.com] > Sent: Thursday, November 01, 2012 9:26 PM > To: dev@lucene.apache.org > Subject: [DISCUSS] Merge DocsEnum and DocsAndPositionsEnum into > PostingsEnum > > hey folks, > > I have spend a hell lot of time on the positions branch to make positions and > offsets working on all queries if needed. The one thing that bugged me the > most is the distinction between DocsEnum and DocsAndPositionsEnum. > Really when you look at it closer DocsEnum is a DocsAndFreqsEnum and if we > omit Freqs we should return a DocIdSetIter. > Same is true for > DocsAndPostionsAndPayloadsAndOffsets*YourFancyFeatureHere*Enum. I > don't really see the benefits from this. We should rather make the interface > simple and call it something like PostingsEnum where you have to specify > flags on the TermsIterator and if we can't provide the sufficient enum we > throw an exception? > I just want to bring up the idea here since it might simplify a lot for users > as > well for us when improving our positions / offset etc. > support. > > thoughts? Ideas? > > simon > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional > commands, e-mail: dev-h...@lucene.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
