lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <>
Subject Re: Gentle Prod: LUCENE-1626 (flexible getPositionIncrementGap)
Date Tue, 18 Aug 2009 00:46:30 GMT
Sorry - not taking the time to properly think.

I got stuck on overriding - was thinking a lot on it on an earlier issue.

Scratch that.

{quote}Not sure how making it protected breaks backcompat. If people are 
calling it directly (in their own inverter? Not sure if that would ever 
happen) they'd be getting the wrong result after the change, because the 
(String, int) version actually becomes the correct public API to find 
the gap.{quote}

Thats a break in back compat - but I guess your saying even if its 
public its a break.

Thats a tough one to push through in my mind then. Though the rarity of 
it affecting anyone might lure someone else to take it on.

- Mark

Paul Cowan wrote:
> Mark Miller wrote:
>> Why wouldn't people overriding the method be declaring it as 
>> protected as well?
> I'm talking about _existing_ code... i.e. if someone already has:
> public class CrazyAnalyzer ... {
>     public int getPositionIncrementGap(String field) {
>       return random.nextInt(100);
>     }
> }
> then my change (making gPIG(String) protected) won't break it. It will 
> also continue to behave as expected due to the default impl of 
> gPIG(String, int).
> Presumably people who are implementing new analyzers after this would 
> make it protected, but it won't break back-compat of existing public 
> overrides.
> Paul
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message