[ 
https://issues.apache.org/jira/browse/LUCENE-6228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16259387#comment-16259387
 ] 

Adrien Grand commented on LUCENE-6228:
--------------------------------------

I think this Scorable interface (or base class) is already great progress as it 
hides advance and other methods that collectors should never call. I tend to 
agree with Alan that Scorable should not have getChildren either but since this 
proves controversial, maybe we can keep it on Scorable for now and discuss it 
in a separate issue?

bq. Another idea I had was to replace getChildren() entirely with a visitor API

For the record, this used to be a visitor API before, see LUCENE-3330. As far 
as I'm concerned, I tend to like exposing well-known java collections better 
than a custom visitor API. Visitors also introduce some challenges in that case 
due to the tree nature of scorers. For instance should it only expose leaves or 
internal nodes as well? And what relationship should it assign to a Scorer that 
is a SHOULD clause of a BooleanQuery which is itself a MUST clause of another 
BooleanQuery?

> Do not expose full-fledged scorers in LeafCollector.setScorer
> -------------------------------------------------------------
>
>                 Key: LUCENE-6228
>                 URL: https://issues.apache.org/jira/browse/LUCENE-6228
>             Project: Lucene - Core
>          Issue Type: Improvement
>            Reporter: Adrien Grand
>            Assignee: Adrien Grand
>             Fix For: 5.2, 6.0
>
>         Attachments: LUCENE-6228.patch, LUCENE-6228.patch, LUCENE-6228.patch, 
> LUCENE-6228.patch
>
>
> Currently LeafCollector.setScorer takes a Scorer, which I don't like because 
> several methods should never be called in the context of a Collector (like 
> nextDoc or advance).
> I think it's even more trappy for methods that might seem to work in some 
> particular cases but will not work in the general case, like getChildren 
> which will not work if you have a specialized BulkScorer or iterating over 
> positions which will not work if you are in a MultiCollector and another leaf 
> collector consumes positions too.
> So I think we should restrict what can be seen from a collector to avoid such 
> traps.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to