On Sun, 2004-04-04 at 22:44, robert burrell donkin wrote: > from my reading of the java specification, moving methods upwards in > the inheritance hierarchy is backwards compatible (in binary terms). > (hopefully someone will correct me if i've made a mistake.) > > it's possible that there are some cases of symantic incompatibility for > user subclasses (overriding the deprecated methods that will never be > called if the rule implementations are changed). since the methods have > been deprecated for a long time now (digester 1.4, i think), for me, > this isn't such an issue (as it once was) provided that it was strongly > highlighted in the release documents. > > i would be interest to hear what other people think about this one > (including lurking users). > > - robert > > On 3 Apr 2004, at 08:06, Simon Kitching wrote: > > > Hi, > > > > I see that a number of Rule classes in digester are still using the > > deprecated versions of the begin/body/end methods. > > > > In a minor-version release (1.5 -> 1.6), are we allowed to change these > > classes to use the newer methods?
What I'm proposing is not to change the Rule class [whose default body(namespace,name,text) method delegates to the deprecated body(text) etc]. What I'm proposing is to fix classes like CallMethodRule and CallParamRule which override the deprecated version, to make them override the "proper" version instead. This should save an extra method call (the undeprecated->deprecated forward in Rule) + make CallParamRule etc compile without deprecation warnings + make sure that people copying-and-pasting from Digester rule source don't end up using the deprecated versions. In binary-compatibility terms, any user class subclassing Rule will be ok, because that class will not change. I *think* that this is in fact a 100% binary-compatible change, but would not bet on it as this isn't a topic I know much about. Regards, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
