Re: GInterfaces and API Stability

[Alexander Larsson <alexl redhat com>]

On Wed, 2007-11-14 at 12:18 +0100, Murray Cumming wrote:
> 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.

That is not strictly needed. GInterface allows you to implement default
fallback code for interface members.