On Thu, 13 Mar 2003 05:42, Noel J. Bergman wrote: > Moving a type from one package to another creates a new type. > Compatibility requires either source changes in the client, or a proxy > class in the old package. > > With respect to method changes, given existing type E, old type O, new type > N: > > Case #1: > > void E.m(O) => void E.m(N) > > Short form: A solution is to have both signatures, and provide the name of > the jar containing O.
I think we can get away with moving parameters to more abstract types as long as long as the more abstract type does not appear as a parameter in the interface previously. This was how it was originally implemented > Case #2: > > O E.m() => N E.m() > > #2.1 O = E.m(); // compatibility requires N extends O > #2.2 f(E.m()); // either N extends O, or add f(N) > > If N does not extend O, the change is incompatible. If N extends O, the > change is source compatible because N can be promoted to O. In the current > case, it means a new class would be extending a deprecated one, but it does > compile. Binary compatibility is also a concern. thats how it used to be. -- Cheers, Peter Donald *----------------------------------------------------------* The phrase "computer literate user" really means the person has been hurt so many times that the scar tissue is thick enough so he no longer feels the pain. -- Alan Cooper, The Inmates are Running the Asylum *----------------------------------------------------------* --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
