Re: Additions to GInterfaces

[Murray Cumming <murrayc murrayc com>]

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

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.
> our
> However, I do agree that signals and properties should be considered a 
> part of the API/ABI.

They are.

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

-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com