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]
