Re: GInterfaces and API Stability

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
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.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]