[
https://issues.apache.org/jira/browse/LUCENE-4524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13559167#comment-13559167
]
Simon Willnauer commented on LUCENE-4524:
-----------------------------------------
this change is really unrelated to LUCENE-2878 it removes a unnecessary
duplication. The fact that Scorer extends DocEnum is not concerning me here
since the main purpose of this class is not the Scorer API. This should really
go on trunk since given the discussion on the list this is independent of
LUCENE-2878.
If there are bugs in reuse we should catch them in the tests no? I mean we can
add even more tests for this particular problem so we catch them quicker. I
would be ok with makeing them abstract but this really is not a big deal here.
I would want to move forward here quickly on trunk at least we can merge later
into 4.x if needed since this might go out of date quickly.
> Merge DocsEnum and DocsAndPositionsEnum into PostingsEnum
> ---------------------------------------------------------
>
> Key: LUCENE-4524
> URL: https://issues.apache.org/jira/browse/LUCENE-4524
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/codecs, core/index, core/search
> Affects Versions: 4.0
> Reporter: Simon Willnauer
> Fix For: 4.2, 5.0
>
> Attachments: LUCENE-4524.patch, LUCENE-4524.patch
>
>
> spinnoff from http://www.gossamer-threads.com/lists/lucene/java-dev/172261
> {noformat}
> 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
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
