lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Muir <rcm...@gmail.com>
Subject Re: [DISCUSS] Merge DocsEnum and DocsAndPositionsEnum into PostingsEnum
Date Thu, 01 Nov 2012 21:04:18 GMT
On Thu, Nov 1, 2012 at 4:55 PM, Uwe Schindler <uwe@thetaphi.de> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message