You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by Shai Erera <se...@gmail.com> on 2008/08/07 10:16:14 UTC
Extending TopDocCollector
Hi
Is it possible to change TopDocCollector members to 'protected' instead of
'package' and 'private'? It will allow to easily extend it. Today, I have a
need to extend it, but since I cannot use its members I have to implement
the getTotalHits() and topDocs() exactly the same as TopDocCollector.
I do not see any issue with this, so if you agree, I'll open a JIRA issue
and post a patch.
Thanks
Shai
Re: Extending TopDocCollector
Posted by Shai Erera <se...@gmail.com>.
Thanks. I created issue
https://issues.apache.org/jira/browse/LUCENE-1356and submitted a
patch.
Do you think it can be included in 2.3.3?
On Wed, Aug 13, 2008 at 4:44 PM, Doron Cohen <cd...@gmail.com> wrote:
> Sounds logical to me. After all, TopDocCollector already has a subclass
>> (TopFieldDocCollector), and it is quite natural that users might want to
>> add more - to implement different sorting mechanisms (e.g., according
>> to payloads, database data, or whatever).
>>
>> Does anyone disagree? Is there a reason why this change should not be
>> done?
>>
>
> I didn't find any reason not to do this.
> One way to bypass this is to create your collector in the same package,
> though I can see this is not always convenient.
> Out of curiosity I looked for other place in the code where a data member
> is declared protected.
> spanFilter in CachingSpanFilter is an example for one.
>
> > I do not see any issue with this, so if you agree, I'll open a JIRA
>> issue and post a patch.
>>
>
> Please do.
>
> Doron
>
Re: Extending TopDocCollector
Posted by Doron Cohen <cd...@gmail.com>.
>
> Sounds logical to me. After all, TopDocCollector already has a subclass
> (TopFieldDocCollector), and it is quite natural that users might want to
> add more - to implement different sorting mechanisms (e.g., according
> to payloads, database data, or whatever).
>
> Does anyone disagree? Is there a reason why this change should not be done?
>
I didn't find any reason not to do this.
One way to bypass this is to create your collector in the same package,
though I can see this is not always convenient.
Out of curiosity I looked for other place in the code where a data member is
declared protected.
spanFilter in CachingSpanFilter is an example for one.
> I do not see any issue with this, so if you agree, I'll open a JIRA issue
> and post a patch.
>
Please do.
Doron
Re: Extending TopDocCollector
Posted by Nadav Har'El <ny...@math.technion.ac.il>.
On Thu, Aug 07, 2008, Shai Erera wrote about "Extending TopDocCollector":
> Is it possible to change TopDocCollector members to 'protected' instead of
> 'package' and 'private'? It will allow to easily extend it. Today, I have a
> need to extend it, but since I cannot use its members I have to implement
> the getTotalHits() and topDocs() exactly the same as TopDocCollector.
Sounds logical to me. After all, TopDocCollector already has a subclass
(TopFieldDocCollector), and it is quite natural that users might want to
add more - to implement different sorting mechanisms (e.g., according
to payloads, database data, or whatever).
Does anyone disagree? Is there a reason why this change should not be done?
--
Nadav Har'El | Wednesday, Aug 13 2008, 12 Av 5768
IBM Haifa Research Lab |-----------------------------------------
|A bird in the hand is safer than one
http://nadav.harel.org.il |overhead.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org