[
https://issues.apache.org/jira/browse/LUCENE-2542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12889745#action_12889745
]
Woody Anderson commented on LUCENE-2542:
----------------------------------------
I'm pretty sure that you cannot usefully pass null to the TDC constructor due
to various final methods (all the public methods are final), e.g.
{code}
/** Returns the top docs that were collected by this collector. */
public final TopDocs topDocs() {
// In case pq was populated with sentinel values, there might be less
// results than pq.size(). Therefore return all results until either
// pq.size() or totalHits.
return topDocs(0, totalHits < pq.size() ? totalHits : pq.size());
}
{code}
Which actually begs the question, should the constructor validate that the PQ
is non-null, as it clearly cannot produce a TopDocs if it is
I imagine there were performance reasons that it was made final? or is
extension in this case frowned upon?
At any rate, I agree that this isn't a "must have", i do think that since a lot
of useful collectors conform to the TDC contract, it's useful to allow that
definition to be extensible to implementations not provided by core lucene.
Code "sharing" is not the only reason to allow for oo abstractions, and though
the implementations don't all belong in core lucene, the ability to refer to
them collectively does have value. I would suggest that the value of the
abstraction is there for more developers than just me, otherwise i wouldn't
have submitted the patch.
I agree with your last comment the most, that IF TDC were extensible for my
purposes, then that would be far superior to my submitted patch of adding
classes.
We could un-final all the public methods of the TDC, which would basically
allow someone to fullfil the contract without using the PQ system TDC is built
upon.
What do you think of that?
> 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
