lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Cowan <co...@aconex.com>
Subject Re: Gentle Prod: LUCENE-1626 (flexible getPositionIncrementGap)
Date Tue, 18 Aug 2009 01:08:06 GMT
Mark Miller wrote:
> Thats a break in back compat - but I guess your saying even if its 
> public its a break.

Agreed, it's a trade-off. Make it protected, and compile-time break any 
custom inverters (if any), or leave it public and (potentially) break 
the inverters anyway (by having them call the wrong method on 
newly-written analyzers) -- but the second one happens silently, at runtime.

> 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.

Yep, it's an interesting one. I mean, I think it's actually very 
low-risk because I can't see anyone having written their own inverter, 
and going to 3.0 (effectively 2.9 is an early 3.0, without removing 
deprecations, yeah?) is the perfect opportunity to do so because that's 
when people expect back-compat to break, even if only in a minor way in 
this case.,

That said, it's almost an impossible situation -- if you've got an API 
exposed publicly that is a final method, you can work around it. If it's 
NOT public, but can be overridden (non-final), you can work around THAT.

But when it's public to users of the class and non-final (indeed, 
intended to be overridden!) there's no way to change the API in any 
substantial way (certainly not by adding params) without breaking one or 
the other use case. Presuming the intent is to allow SOME changes to the 
API where required, I think this one is low risk but interested to see 
what others think.

Cheers,

Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org


Mime
View raw message