Re: GInterfaces and API Stability

[Murray Cumming <murrayc murrayc com>]

On Wed, 2007-11-14 at 10:50 +0100, BJörn Lindqvist wrote:
> On Nov 14, 2007 7:54 AM, Kalle Vahlman <kalle vahlman gmail com> wrote:
> > Matthias is right IMO, if you need to limit the additions of
> > GInterface methods for C#, it should be done by the binding. Of
> > course, if this is a more general problem, *then* it might be
> > approperiate to refrain from adding interface methods in stable
> > series. But it doesn't seem to be so.
> 
> Lets say GTK+ 2.14 adds the function gtk_ibar_fiddle_foo() to the
> interface GtkIBar. If I use the GtkIBar interface I except the
> gtk_ibar_fiddle_foo() method to be there. If a method in another
> library compiled against GTK+ 2.12 returns a new GtkIBar object then
> the gtk_ibar_fiddle_foo() method will not be present. The likely
> result is a segfault in my program when I call gtk_ibar_fiddle_foo().

I guess that new vfuncs are usually tested for NULL before being called.
Actually, I'd expect this for all vfuncs. In general, I'd expect the
interface to adapt to not having its new vfuncs implemented. C can do
that.

> So yes, adding interface methods is definitely breaks both API and ABI
> stability.
>
> Python bindings doesn't force you to implement all methods an
> interface specifies so adding interface methods doesn't break the
> program directly. But you still get a segfault sooner or later when
> the nonexistent method is called.

-- 
murrayc murrayc com
www.murrayc.com
www.openismus.com