[
https://issues.apache.org/jira/browse/LUCENE-6845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14965473#comment-14965473
]
David Smiley commented on LUCENE-6845:
--------------------------------------
I looked it over; I like the conceptual simplification this bring. One thing
confused me though: What is the purpose of SpanNotQueryâs getSpanScorer
wrapping the includeSpans with a FilterSpans that has an accept that always
returns YES? I see this in SpanOrQuery too and perhaps others.
The rename of Spans -> SpanScorer affects anyone consuming Spans, not just
implementers of custom Spans. This is seen in your patch in
WeightedSpanTermExtractor, for example. I'm on the fence if this is acceptable
or not in a point release; I wonder what others think. Even if we decide to
keep backward compatibility, I think the substance of your patch could still
land in 5x by having Spans not be renamed to SpanScorer, and keep the existing
method names as-is.
> Merge Spans and SpanScorer
> --------------------------
>
> Key: LUCENE-6845
> URL: https://issues.apache.org/jira/browse/LUCENE-6845
> Project: Lucene - Core
> Issue Type: Improvement
> Reporter: Alan Woodward
> Assignee: Alan Woodward
> Fix For: Trunk, 5.4
>
> Attachments: LUCENE-6845.patch, LUCENE-6845_norenames.patch
>
>
> SpanScorer and Spans currently share the burden of scoring span queries, with
> SpanScorer delegating to Spans for most operations. Spans is essentially a
> Scorer, just with the ability to iterate through positions as well, and no
> SimScorer to use for scoring. This seems overly complicated. We should
> merge the two classes into one.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
