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 can. 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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
