Re: GInterfaces and API Stability

[Alexander Larsson <alexl redhat com>]

On Thu, 2007-11-15 at 11:28 +0100, Paolo Molaro wrote:
> 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).

This is because someone other than Tim wrote those docs. GObject
interfaces was not modeled on Java style interfaces, but rather on an
gcc c++ extension calles signatures, which is slightly different than
java interfaces.

> 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

I believe C++ could work around the new methods approach by padding
classes with stub vcalls and using those for new methods.

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

If you install a default handler for the new interface method there is
never any NULL problem.

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

There is another dimension too. Extension of an interface is often the
most natural way for people using the interface in C. Having a totally
new interface for a minor optional addition to an interface is pretty
ugly.