Re: Additions to GInterfaces

[Johan Dahlin <johan gnome org>]

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.

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. Which also
should be considered stable, I know that during the stable 2.6.x series
methods were added.

Does gtk-doc need additions/modifications to support these additional
interfaces, so it's easy to see if they're added by mistake? (Or is it 
up to another tool to verify that the API stability is honored?)

Johan