Re: GInterfaces and API Stability

[Paolo Molaro <lupus ximian com>]

On 11/14/07 Sven Herzberg wrote:
> I think it's not about "the compiler doesn't barf". It was a design
> decision to be able to always extend interfaces. The only thing GTK+

I guess this is a documentation issue, then, as this design decision
is not mentioned at all in the GObject documentation at
http://library.gnome.org/devel/gobject/unstable/gtype-non-instantiable-classed.html.

It actually says that GInterfaces are very similar to Java interfaces
but Java interfaces definitely don't allow adding new methods
(without breaking previously working code).

> (talking about the concrete additions) has to handle non-implementations
> gracefully, which it easily can by NULL-checking before calling into the
> interface implementation. Even a default implementation can be added to
> be called if the interface function is not explicitly implemented.
> 
> This reminds me of the Microsoft API Design video that Philipp van Hoof
> has blogged about. The speaker even claims that MS is extending their
> .Net-interfaces in similar ways.

I didn't watch that video, but this claim looks strange. Adding a method
to an interface in C#/CLI will break the code and I don't know of a
single case where this happened. What happens instead is that a new
interface is defined and the relevant types are extended to implement
the new interface. This is exactly what Mike suggested.
Regardless, even if a future .net implementation allowed adding methods
to interfaces, this wouldn't address Java's needs (but I don't know the
status of the java bindings: do they support GInterfaces at all?And if
they do, do they use Java interfaces? In the following I assume they do).

So, let's create a table with the options available in the C libs and
in the bindings and see if there is a compromise that would make most
people happy. Please comment on this, as my understanding of some of the
bindings is lacking.

In GObject (and Gtk+) we have two options: adding new methods to
existing interfaces or adding new interfaces. Let's see how the major
bindings cope with this:

		new methods	new interface
Python		doesn't care	doesn't care
Perl		doesn't care	doesn't care
Ruby		doesn't care	doesn't care
C++		ABI break	ABI break
Java		ABI break	OK
C#		ABI break	OK

Here "doesn't care" means that the language doesn't really care much about
the issue, though there may be problems as the mentioned
NULL dereferences (nothing much can be done in Gtk+ here, except what
Sven rightly mentioned about checking for NULL method implementations
and updating the documentation to match, so other people follow this
pattern as well).

"ABI break" means that following the existing implementation of
GInterfaces for the language (or following the most natural
implementation of the concept for the language) the ABI would break
when the change is introduced. There may be workarounds (like just
using the C function in C++ or explicitly adding new interfaces for C#
and Java).

If the above table is correct (please send me corrections or add more
language bindings) it seems that adding new interfaces would be the
preferred extension mechanism.

lupus

-- 
-----------------------------------------------------------------
lupus debian org                                     debian/rules
lupus ximian com                             Monkeys do it better