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

Michael McCandless commented on LUCENE-1614:
--------------------------------------------

bq. Agreed. I'll take a look at the code and check if that's possible. I 
thought to do it, but since Scorer is public, and score(Collector, int) is 
protected, I didn't feel that making this assumption is a good thing and might 
break back-compat (i.e., if someone overrode Scorer and call this method w/o 
calling nextDoc() first).

Well the javadoc clearly states the requirement ("next must be called").  And 
if external Scorers are violating this, it'll cause problems if their used as 
sub-scorers by BooleanScorer.

bq.  But I've seen cases, like ReqExclScorer where NPE may be thrown, or 
AIOOBE. That's what I would like to document - that impl should try to avoid 
it. Since I don't have a way in Java to restrict that, I'd like that to appear 
in the javadocs.

Under what cases are NPE & AIOOBE thrown by ReqExclScorer?  (That doesn't seem 
right).

I don't think we need to document that you shouldn't throw RuntimeExceptions -- 
that's pretty much par for the course, right?  Or maybe I'm missing 
something... does something go horribly wrong in particular if an exception is 
thrown by docID()?

> Add next() and skipTo() variants to DocIdSetIterator that return the current 
> doc, instead of boolean
> ----------------------------------------------------------------------------------------------------
>
>                 Key: LUCENE-1614
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1614
>             Project: Lucene - Java
>          Issue Type: Improvement
>          Components: Search
>            Reporter: Shai Erera
>             Fix For: 2.9
>
>         Attachments: LUCENE-1614.patch, LUCENE-1614.patch, LUCENE-1614.patch, 
> LUCENE-1614.patch, LUCENE-1614.patch, LUCENE-1614.patch, LUCENE-1614.patch
>
>
> See 
> http://www.nabble.com/Another-possible-optimization---now-in-DocIdSetIterator-p23223319.html
>  for the full discussion. The basic idea is to add variants to those two 
> methods that return the current doc they are at, to save successive calls to 
> doc(). If there are no more docs, return -1. A summary of what was discussed 
> so far:
> # Deprecate those two methods.
> # Add nextDoc() and skipToDoc(int) that return doc, with default impl in DISI 
> (calls next() and skipTo() respectively, and will be changed to abstract in 
> 3.0).
> #* I actually would like to propose an alternative to the names: advance() 
> and advance(int) - the first advances by one, the second advances to target.
> # Wherever these are used, do something like '(doc = advance()) >= 0' instead 
> of comparing to -1 for improved performance.
> I will post a patch shortly

-- 
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