Re: GInterfaces and API Stability

On Wed, 2007-11-14 at 22:01 +0100, Alexander Larsson wrote:
> > I think this is similar to a problem we have in gtkmm. When a GTK+
> > widget implements an extra GInterface, we can't just add a base
> class to
> > our existing C++ class, because that would break ABI in C++. So we
> just
> > don't wrap it, and tell people to use the C API when they need to
> use
> > that part of the API. It doesn't happen much, luckily.
> Wow. Combine this "no new interfaces" with the C# "no new methods in
> interfaces" and its clearly obvious that we can't make all bindings
> happy and still make progress.

Yeah, but C++ doesn't have a real notion of interfaces to begin with so
it seems like any implementation is going to feel non-native to that
language.  So if you have to pick one of the above options, it seems
like it would be a huge benefit to languages like Java and C# to go with
the "no new methods in interfaces" option, and let bindings for
languages without native interfaces deal with it in whatever way they

If GObject supported multiple inheritance, it wouldn't make much sense
to enforce a pattern of using that feature according to constraints set
by C# or Java bindings.

/ Cody

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]