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: [email protected] For additional commands, e-mail: [email protected]
