lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shai Erera (JIRA)" <>
Subject [jira] Commented: (LUCENE-1849) Add OutOfOrderCollector and InOrderCollector subclasses of Collector
Date Mon, 24 Aug 2009 20:02:59 GMT


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:
>             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:
For additional commands, e-mail:

View raw message