[coyotos-dev] IDL compatibility: the versioning nightmare

[Jonathan S. Shapiro]

On Tue, 2007-07-10 at 09:04 -0400, Christopher Nelson wrote:
>           1. Everything that can be correctly expressed with
>         versioning
>              can equally well be expressed with inheritance, so
>         explicit 
>              versioning mechanism is technically required.
>         
>           2. Versioning is a nightmare. Forcing it to be expressed
>         through
>              inheritance helps make the nightmare more explicit. I, at
>         least,
>              believe that software nightmares should not be kept in
>         closets. 
>         
> 
> Out of curiosity, do you consider the approach of having one dispatch
> list per version per interface to code heavy and/or to slow?
> 
> In other words, say you had:
> 
> interface A:0
> {
>    mymethod1();
> }
> 
> interface A:1
> {
>   mymethod2();
> }

Umm. No. I said I had:

  interface A_0 {
     void methodOne();
  };

  interface A_1 extends A_0 {
     void methodTwo();
  };

The method table in this case is shared, which is fine.

Charlie Landau proposed an alternative similar to yours:

  interface A_0 {
     void methodOne();
  };

  interface A_1 {
     void methodOne();
     void methodTwo();
  };

In this case the method table is not shared.

I do not see any intrinsic advantage to Charlie's approach so long as we
are *adding* methods. The instant a method is *dropped* then we are no
longer looking at inheritance, and a distinct interface is required.

> Downwards compatibility is maintained because the dispatch
> list/table/function only changes in the latest version of the
> interface.

As long as code points do not collide, downward compatibility is
maintained in either design as long as identifiers are not dropped.

>   There might also be syntactic sugar allowing you to specify in
> source that you want the latest version of the interface.  This
> wouldn't have any effect on binary compatibility with already-compiled
> apps, though. 

Of course it would! You declare that you want the latest version. Some
method has been dropped. You then pass that cap to one of your services.
That service needs the old method. Game over.

The root problem here is that method obsolesence requires distributed
agreement among developers, and that is hard to accomplish.

shap