serera at gmail
Nov 11, 2009, 11:47 AM
Post #4 of 4
(478 views)
Permalink
|
|
Re: TopDocsCollector's generic definition
[In reply to]
|
|
Hi Uwe, I can open an issue and fix it if it'll help you handle that huge
pile of issues you seem to be involved recently :)
Shai
On Wed, Nov 11, 2009 at 8:45 PM, Uwe Schindler <uwe [at] thetaphi> wrote:
> Can you open an issue, I am currently fixing it? This was a lapsus of
> myself to let the generification patch let in that way. Indeed FieldValueHitQueue.Entry
> should extend ScoreDoc and then all looks better. I have to check for 2.9
> backwards breaks if I change this.
>
>
>
> This is one example why type safety is good and why you **not** should use
> Eclipse to infer generics…
>
>
>
> Uwe
>
> -----
> Uwe Schindler
> H.-H.-Meier-Allee 63, D-28213 Bremen
> http://www.thetaphi.de
> eMail: uwe [at] thetaphi
> ------------------------------
>
> *From:* Shai Erera [mailto:serera [at] gmail]
> *Sent:* Wednesday, November 11, 2009 6:01 PM
> *To:* java-dev [at] lucene
> *Subject:* TopDocsCollector's generic definition
>
>
>
> Hi
>
>
> TopDocsCollector was changed to be TopDocsCollector<T>. However it has
> methods which specifically assume the PQ stores ScoreDoc. So I think that if
> I extend it and pass in a NotAtAllScoreDoc object, things will break?
>
> I think we shouldn't put <T> on TopDocsCollector at all, but rather change
> its ctor to protected TopDocsCollector(PriorityQueue<? extends ScoreDoc>
> pq). TopDocsCollector should handle ScoreDoc types. If we do this, we'll
> need to change FieldValueHitQueue's Entry to extend ScoreDoc (why doesn't it
> do it anyway?).
>
> I'm using the latest trunk version, and I don't know if this can be changed
> in 3.0 or not (feels like it can).
>
> Shai
>
|
