Re: Additions to GInterfaces
- From: Murray Cumming <murrayc murrayc com>
- To: Johan Dahlin <johan gnome org>
- Cc: gtk-devel-list gnome org
- Subject: Re: Additions to GInterfaces
- Date: Thu, 01 Dec 2005 18:01:14 +0100
On Thu, 2005-12-01 at 14:07 -0200, Johan Dahlin wrote:
> Mike Kestner wrote:
> > When auditing the new API in 2.8 for Gtk#, I noticed that a property and
> > signal were added to the FileChooser interface. Adding anything to an
> > interface is a non-compatible change, because any class implementing the
> > interface must be updated to add the new API members. Whether a C
> > compiler would complain or not, conceptually it's a breaking change and
> > will most likely cause trouble for any language binding that supports
> > interfaces.
> > Since we haven't added GInterface registration to Gtk# yet, I'm going to
> > just let this break occur in Gtk# as well. It's only non-compatible for
> > implementors, not consumers. We do plan to support GInterface
> > registration in an upcoming release though, so I would like to request
> > that interface stability be guaranteed in future releases.
Luckily, that wasn't a big problem for gtkmm, if we avoid having a
virtual default signal handler.
What was even more problematic for us was that, since 2.6, ComboBox now
implements the GtkCellEditable interface, and we can't add a new base
class (we wrap interfaces as multiply-inherited base classes) without
But I guessed that the C people wouldn't want to be constrained by the
ABI system used by C++, so we document/workaround these small things.
The change in GTK+ doesn't break things - it just forces you to break
things you to break things yourself if you want to wrap the new API.
I suppose that you might experience a silent ABI break if your generator
wraps new things automatically. But in gtkmm, our API is explicitly
(laboriously) defined and the generator just fills in the implementation
between our human-written C++ API and the human-written C API.
> Depends on the language bindings of course, python will introspect
> everything so adding properties and/or signals will work just fine.
> However, I do agree that signals and properties should be considered a
> part of the API/ABI.
> I'd also like anything which is added to the public
> class and object structs, such as fields and virtual methods.
They are already considered public ABI too.
> Which also
> should be considered stable, I know that during the stable 2.6.x series
> methods were added.
I don't think virtual functions were added without using existing
padding to do it. That would break things pretty quickly.
> Does gtk-doc need additions/modifications to support these additional
> interfaces, so it's easy to see if they're added by mistake?
I guess that since: works for signals and properties already.
> (Or is it
> up to another tool to verify that the API stability is honored?)
murrayc murrayc com
] [Thread Prev