lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: [DISCUSS] Merge DocsEnum and DocsAndPositionsEnum into PostingsEnum
Date Thu, 01 Nov 2012 22:00:54 GMT
+1, this makes total sense!

Mike McCandless

On Thu, Nov 1, 2012 at 5:04 PM, Robert Muir <> wrote:
> On Thu, Nov 1, 2012 at 4:55 PM, Uwe Schindler <> 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:
> 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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message