Re: GInterfaces and API Stability
- Date: Wed, 14 Nov 2007 08:23:42 +0000
- From: Alp Toker <alp@xxxxxxxxxx>
- Subject: Re: GInterfaces and API Stability
Kalle Vahlman wrote:
> 2007/11/14, Alp Toker <alp@xxxxxxxxxx>:
>> 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.
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-devel-list