Re: GInterfaces and API Stability

["Mike Kestner" <mkestner novell com>]

On Wed, 2007-11-07 at 22:42 -0500, Owen Taylor wrote:

> > > I'm hoping this is just one of those "oops, never thought of that" kinds
> > > of issues and the gtk+ and atk maintainers will avoid extending these
> > > stable interfaces going forward.  It's a significant binding support
> > > issue.
> > 
> > Well, I have certainly considered C ABI compatibility to be the main deciding
> > factor when  making such decisions. I'd say if C# interfaces are inflexible like
> > that then mapping GObject interfaces directly to C# interfaces was probably
> > wrong.
> 
> One option that a language binding would be have would be to map the
> extension of a GTK+ interface into
> 
>  GtkBorkable                        /* original version */
>  GtkBorkable212 extends GtkBorkable /* new version with new methods in 2.12 */

Of course, if gtk+ adopted this convention itself, or better yet added a
new interface for the added API, the language bindings could maintain a
consistent naming with gtk+ itself.  

Both the interface declaration and all of the API points which expose
that type would have to be extended if it's up to the binding to work
around these changes.  In C#, any method which returns an interface or
any property with an interface type would also require name kludging to
support the additions, for example.  The situation does indeed get very
ugly quickly.

Other than the boilerplate code to add a new interface, is there any
tangible cost to adding these methods under new interfaces?  Aren't
there already numerous examples of places where gtk+ adopts a policy
specifically for the benefit of binding support?  I don't understand the
reluctance on this point.

-- 
Mike Kestner <mkestner novell com>