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

Shai Erera commented on LUCENE-1849:
------------------------------------

But if we encourage people to extend AbstractCollector, they'll incur some 
overhead we've tried to eliminate. Why have a setScorer impl which does 
something, even if just member assignment, if I don't need the score?

Keeping Scorer private is not good either, because that'll add a method call 
for me (score() vs. scorer.score()). This is also something we've tried to 
avoid in all these "specialized" impls in TSDC/TFC.

Part of the new Collector API is to help Collector developers impl the best 
Collector for their needs. By having those methods abstract, we force them to 
think a little bit and then do what's best for them. If I don't need a score, I 
don't even want to have a Scorer member in my Collector (which consumes memory, 
even if just a pointer).

I'm afraid that by introducing this AbstractCollector, we won't encourage 
people to impl the best Collector for their needs. They'll just impl collect() 
and use whatever is available if they need to. And really, IMO, this 
AbstractCollector saves me nothing - I don't mind writing this.scorer = scorer 
if I need Scorer. And I don't think the current Collector API makes it any more 
harder to write a Collector ... but perhaps I'm wrong.

> Add OutOfOrderCollector and InOrderCollector subclasses of Collector
> --------------------------------------------------------------------
>
>                 Key: LUCENE-1849
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1849
>             Project: Lucene - Java
>          Issue Type: Wish
>          Components: Search
>    Affects Versions: 2.9
>            Reporter: Tim Smith
>            Priority: Minor
>             Fix For: 2.9
>
>
> I find myself always having to implement these methods, and i always return a 
> constant (depending on if the collector can handle out of order hits)
> would be nice for these two convenience abstract classes to exist that 
> implemented acceptsDocsOutOfOrder() as final and returned the appropriate 
> value

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


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

Reply via email to