Re: GInterfaces and API Stability

[Alp Toker <alp atoker com>]

Kalle Vahlman wrote:
> 2007/11/14, Alp Toker <alp atoker com>:
> > Matthias Clasen wrote:
> > > Well, I have certainly considered C ABI compatibility to be the main deciding
> > > factor when  making such decisions. I'd say if C# interfaces are inflexible like
> > > that then mapping GObject interfaces directly to C# interfaces was probably
> > > wrong.
> > This is totally missing the point. GObject interfaces exist to formalise
> > a pattern of design by contract. Even if the C compiler doesn't catch
> > and report incomplete interface implementations, that doesn't make it
> > correct to ship code that breaks the rules.
> >
> > Your argument is analogous to claiming that it's OK to change property
> > and signal names and parameters in an ABI-stable release because the C
> > compiler won't notice that anything has broken.
>
> No, it would be analogous to *adding* new properties and signals
> (while maintaining ABI compatibility).

This is absolutely wrong.

It's fine to add new signals, properties and functions to a type, since 
it's the only type being extended. Subclasses and application code can 
choose to use the new entry points or ignore them.

An interface, on the other hand, is a description of the minimal 
functionality a type must implement. It's a list of requirements.

The Wikipedia article explains this quite well:

"In object-oriented programming, an object's interface consists of a set 
of methods that the object must respond to."

Notice the word "must". It is central to the concept of interfaces.

In other words, when I get an object that claims to implement some 
interface, I really do expect it to implement all the functionality that 
the interface describes.

If you've been using GObject interfaces as some kind of general purpose 
virtual function table until now, I'd say it's time to fix your code.