Re: GInterfaces and API Stability

[Alexander Larsson <alexl redhat com>]

On Wed, 2007-11-14 at 10:08 -0600, Mike Kestner wrote:
> On Wed, 2007-11-14 at 14:00 +0100, Alexander Larsson wrote:
> 
> > > 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.
> 
> The problem with this capability is that it produces ambiguity in the
> API.  If I am developing an application and I see that GtkCellLayout
> exposes a GetCells method, and I use a widget from libfoo which
> implements GtkCellLayout, but not the version of GtkCellLayout that
> exposes GetCells, I have to know that explicitly or my program is going
> to produce unexpected results.  I don't see how a fallback
> implementation of GetCells can do anything but avoid crashes and return
> null.

In the case you describe GetCells is a pretty core part of the
interface, and its clearly hard to not have it do much. However, that
doesn't mean there are times when its useful. For instance, the default
implementation of the method could call other methods on the interface,
allowing you to add an extended method with a fallback to the previous
unextended implementation.

Another example is an interface that is a bit more generic, like GFile
in libgio. You could add a new file operation that wasn't previously
supported in a compatible way by having the default operation return a
G_IO_ERROR_NOT_SUPPORTED. Code using this have to expect that errors can
happen anyway, as some backends might not be able to implement all
operations.