[
https://issues.apache.org/jira/browse/LUCENE-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12889581#action_12889581
]
Shai Erera commented on LUCENE-2542:
------------------------------------
First, we didn't make an interface out of Collector or any of its derivatives
on purpose - that's the approach that's adopted in many places of the code -
when you want to add a method, it's impossible to do it with an interface w/o
breaking back-compat, while abstract classes give us the freedom to do so w/ a
default impl (when possible).
You can already sub-class TDC and not rely on its PQ, by passing null to its
ctor and override all of the topDocs methods. I agree that looks odd (why pass
null in the first place). But then, there is a point where you need to ask
yourself "what must be in core Lucene", "what is a nice to have" and "what is
completely app-specific usage". Collector is a "must have in core", no
arguments about it. Previously, TDC was actually TSDC and had only one
derivative -- TFC. But a while ago, when the Collector API was changed, TDC was
created for TSDC and TFC to override it (rather than TFC overriding TSDC) and a
"nice to have" side effect was that app-specific PQ-based collectors can
override TDC as well.
The question I'm asking myself is whether a generic "TDC", which will be
entirely abstract -- no chance for common impl, perhaps except for
getTotalHits(), which is redundant 'cause TopDocs has totalHits already -- is a
"nice to have" in Lucene. It's certainly not a "must have" ... and it adds
complexity more than it simplifies the API. After all, Lucene's external API
accepts and handles Collector. Internally it creates TSDC or TFC. It couldn't
care less what those two extend.
It seems to me that only the app will benefit from having this abstraction, and
seems to me you can do so w/o having TDC in core Lucene. You can have your own
TDC, w/ a wrapper for "Lucene TDCs" and your own extensions ...
> TopDocsCollector should be abstract super class that is the real
> "TopDocsCollector" contract, a subclass should implement the priority-queue
> logic. e.g. PQTopDocsCollector
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: LUCENE-2542
> URL: https://issues.apache.org/jira/browse/LUCENE-2542
> Project: Lucene - Java
> Issue Type: Improvement
> Components: Search
> Affects Versions: 3.0.2
> Reporter: Woody Anderson
> Fix For: 4.0
>
> Attachments: LUCENE-2542.patch, LUCENE_3.0.2-2542.patch
>
>
> TopDocsCollector is both an abstract interface for producing TopDocs as well
> as a PriorityQueue based implementation.
> Not all Collectors that could produce TopDocs must use a PriorityQueue, and
> it would be advantageous to allow the TopDocsCollector to be an "interface"
> type abstract class, with a PQTopDocsCollector sub-class.
> While doing this, it'd be good to clean up the generics uses in these
> classes. As it's odd to create a TopFieldCollector and have to case the
> TopDocs object, when this can be fixed with generics.
--
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
