Re: Deprecation, repackaging, and compatibility

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