Re: GInterfaces and API Stability
On 11/14/07 Sven Herzberg wrote: I think it's not about the compiler doesn't barf. It was a design decision to be able to always extend interfaces. The only thing GTK+ I guess this is a documentation issue, then, as this design decision is not mentioned at all in the GObject documentation at http://library.gnome.org/devel/gobject/unstable/gtype-non-instantiable-classed.html. It actually says that GInterfaces are very similar to Java interfaces but Java interfaces definitely don't allow adding new methods (without breaking previously working code). (talking about the concrete additions) has to handle non-implementations gracefully, which it easily can by NULL-checking before calling into the interface implementation. Even a default implementation can be added to be called if the interface function is not explicitly implemented. This reminds me of the Microsoft API Design video that Philipp van Hoof has blogged about. The speaker even claims that MS is extending their .Net-interfaces in similar ways. I didn't watch that video, but this claim looks strange. Adding a method to an interface in C#/CLI will break the code and I don't know of a single case where this happened. What happens instead is that a new interface is defined and the relevant types are extended to implement the new interface. This is exactly what Mike suggested. Regardless, even if a future .net implementation allowed adding methods to interfaces, this wouldn't address Java's needs (but I don't know the status of the java bindings: do they support GInterfaces at all?And if they do, do they use Java interfaces? In the following I assume they do). So, let's create a table with the options available in the C libs and in the bindings and see if there is a compromise that would make most people happy. Please comment on this, as my understanding of some of the bindings is lacking. In GObject (and Gtk+) we have two options: adding new methods to existing interfaces or adding new interfaces. Let's see how the major bindings cope with this: new methods new interface Python doesn't caredoesn't care Perldoesn't caredoesn't care Rubydoesn't caredoesn't care C++ ABI break ABI break JavaABI break OK C# ABI break OK Here doesn't care means that the language doesn't really care much about the issue, though there may be problems as the mentioned NULL dereferences (nothing much can be done in Gtk+ here, except what Sven rightly mentioned about checking for NULL method implementations and updating the documentation to match, so other people follow this pattern as well). ABI break means that following the existing implementation of GInterfaces for the language (or following the most natural implementation of the concept for the language) the ABI would break when the change is introduced. There may be workarounds (like just using the C function in C++ or explicitly adding new interfaces for C# and Java). If the above table is correct (please send me corrections or add more language bindings) it seems that adding new interfaces would be the preferred extension mechanism. lupus -- - [EMAIL PROTECTED] debian/rules [EMAIL PROTECTED] Monkeys do it better ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GInterfaces and API Stability
On Thu, 2007-11-15 at 11:28 +0100, Paolo Molaro wrote: On 11/14/07 Sven Herzberg wrote: I think it's not about the compiler doesn't barf. It was a design decision to be able to always extend interfaces. The only thing GTK+ I guess this is a documentation issue, then, as this design decision is not mentioned at all in the GObject documentation at http://library.gnome.org/devel/gobject/unstable/gtype-non-instantiable-classed.html. It actually says that GInterfaces are very similar to Java interfaces but Java interfaces definitely don't allow adding new methods (without breaking previously working code). This is because someone other than Tim wrote those docs. GObject interfaces was not modeled on Java style interfaces, but rather on an gcc c++ extension calles signatures, which is slightly different than java interfaces. So, let's create a table with the options available in the C libs and in the bindings and see if there is a compromise that would make most people happy. Please comment on this, as my understanding of some of the bindings is lacking. In GObject (and Gtk+) we have two options: adding new methods to existing interfaces or adding new interfaces. Let's see how the major bindings cope with this: new methods new interface Pythondoesn't caredoesn't care Perl doesn't caredoesn't care Ruby doesn't caredoesn't care C++ ABI break ABI break I believe C++ could work around the new methods approach by padding classes with stub vcalls and using those for new methods. Java ABI break OK C#ABI break OK Here doesn't care means that the language doesn't really care much about the issue, though there may be problems as the mentioned NULL dereferences (nothing much can be done in Gtk+ here, except what Sven rightly mentioned about checking for NULL method implementations and updating the documentation to match, so other people follow this pattern as well). If you install a default handler for the new interface method there is never any NULL problem. If the above table is correct (please send me corrections or add more language bindings) it seems that adding new interfaces would be the preferred extension mechanism. There is another dimension too. Extension of an interface is often the most natural way for people using the interface in C. Having a totally new interface for a minor optional addition to an interface is pretty ugly. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GInterfaces and API Stability
On Thu, 2007-11-15 at 01:16 +0100, Mathias Hasselmann wrote:
Wouldn't it possible to implement the GInterface as C++ class and add
an
operator like this to the GObject wrapper class:
public:
GLib::RefPtrGFooInterface operator () {
return GLib::wrap_interface (gobj ());
}
As well as a general learned avoidance of reckless C++ operator
overloading, I think you'd lose the advantages of actually using the
regular C++ hierarchy, such as type-safe casts at compile-time.
For gtkmm I am not greatly troubled by the new-interfaces-break-ABI
issue because it happens so rarely.
--
[EMAIL PROTECTED]
www.murrayc.com
www.openismus.com
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GInterfaces and API Stability
Kalle Vahlman wrote: 2007/11/14, Alp Toker [EMAIL PROTECTED]: Matthias Clasen wrote: 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. This is totally missing the point. GObject interfaces exist to formalise a pattern of design by contract. Even if the C compiler doesn't catch and report incomplete interface implementations, that doesn't make it correct to ship code that breaks the rules. Your argument is analogous to claiming that it's OK to change property and signal names and parameters in an ABI-stable release because the C compiler won't notice that anything has broken. No, it would be analogous to *adding* new properties and signals (while maintaining ABI compatibility). This is absolutely wrong. It's fine to add new signals, properties and functions to a type, since it's the only type being extended. Subclasses and application code can choose to use the new entry points or ignore them. An interface, on the other hand, is a description of the minimal functionality a type must implement. It's a list of requirements. The Wikipedia article explains this quite well: In object-oriented programming, an object's interface consists of a set of methods that the object must respond to. Notice the word must. It is central to the concept of interfaces. In other words, when I get an object that claims to implement some interface, I really do expect it to implement all the functionality that the interface describes. If you've been using GObject interfaces as some kind of general purpose virtual function table until now, I'd say it's time to fix your code. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GInterfaces and API Stability
On Nov 14, 2007 7:54 AM, Kalle Vahlman [EMAIL PROTECTED] wrote: Matthias is right IMO, if you need to limit the additions of GInterface methods for C#, it should be done by the binding. Of course, if this is a more general problem, *then* it might be approperiate to refrain from adding interface methods in stable series. But it doesn't seem to be so. Lets say GTK+ 2.14 adds the function gtk_ibar_fiddle_foo() to the interface GtkIBar. If I use the GtkIBar interface I except the gtk_ibar_fiddle_foo() method to be there. If a method in another library compiled against GTK+ 2.12 returns a new GtkIBar object then the gtk_ibar_fiddle_foo() method will not be present. The likely result is a segfault in my program when I call gtk_ibar_fiddle_foo(). So yes, adding interface methods is definitely breaks both API and ABI stability. Python bindings doesn't force you to implement all methods an interface specifies so adding interface methods doesn't break the program directly. But you still get a segfault sooner or later when the nonexistent method is called. -- mvh Björn ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GInterfaces and API Stability
On Wed, 2007-11-14 at 10:50 +0100, BJörn Lindqvist wrote: On Nov 14, 2007 7:54 AM, Kalle Vahlman [EMAIL PROTECTED] wrote: Matthias is right IMO, if you need to limit the additions of GInterface methods for C#, it should be done by the binding. Of course, if this is a more general problem, *then* it might be approperiate to refrain from adding interface methods in stable series. But it doesn't seem to be so. Lets say GTK+ 2.14 adds the function gtk_ibar_fiddle_foo() to the interface GtkIBar. If I use the GtkIBar interface I except the gtk_ibar_fiddle_foo() method to be there. If a method in another library compiled against GTK+ 2.12 returns a new GtkIBar object then the gtk_ibar_fiddle_foo() method will not be present. The likely result is a segfault in my program when I call gtk_ibar_fiddle_foo(). I guess that new vfuncs are usually tested for NULL before being called. Actually, I'd expect this for all vfuncs. In general, I'd expect the interface to adapt to not having its new vfuncs implemented. C can do that. So yes, adding interface methods is definitely breaks both API and ABI stability. Python bindings doesn't force you to implement all methods an interface specifies so adding interface methods doesn't break the program directly. But you still get a segfault sooner or later when the nonexistent method is called. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GInterfaces and API Stability
On Wed, 2007-11-14 at 12:02 +, Gustavo J. A. M. Carneiro wrote: I guess that new vfuncs are usually tested for NULL before being called. Actually, I'd expect this for all vfuncs. In general, I'd expect the interface to adapt to not having its new vfuncs implemented. C can do that. Not all C code does that. But I think they should. -- [EMAIL PROTECTED] www.murrayc.com www.openismus.com ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GInterfaces and API Stability
On Qua, 2007-11-14 at 12:18 +0100, Murray Cumming wrote: On Wed, 2007-11-14 at 10:50 +0100, BJörn Lindqvist wrote: On Nov 14, 2007 7:54 AM, Kalle Vahlman [EMAIL PROTECTED] wrote: Matthias is right IMO, if you need to limit the additions of GInterface methods for C#, it should be done by the binding. Of course, if this is a more general problem, *then* it might be approperiate to refrain from adding interface methods in stable series. But it doesn't seem to be so. Lets say GTK+ 2.14 adds the function gtk_ibar_fiddle_foo() to the interface GtkIBar. If I use the GtkIBar interface I except the gtk_ibar_fiddle_foo() method to be there. If a method in another library compiled against GTK+ 2.12 returns a new GtkIBar object then the gtk_ibar_fiddle_foo() method will not be present. The likely result is a segfault in my program when I call gtk_ibar_fiddle_foo(). I guess that new vfuncs are usually tested for NULL before being called. Actually, I'd expect this for all vfuncs. In general, I'd expect the interface to adapt to not having its new vfuncs implemented. C can do that. Not all C code does that. I recall for instance goocanvas, which often does not check for NULL vfuncs, and so my python programs just segfault when I forget to implement some method in custom canvas items. I have to agree that interfaces being frozen would significantly improve the stability of a platform. It also would help clarify which APIs are new to which library version. And while we're at it, virtual methods (in interface or otherwise) should _not_ have their return value type changed from void to boolean, like it happened for some GtkNotebook vmethods between gtk+ 2.10 and 2.12. So yes, adding interface methods is definitely breaks both API and ABI stability. Python bindings doesn't force you to implement all methods an interface specifies so adding interface methods doesn't break the program directly. But you still get a segfault sooner or later when the nonexistent method is called. So true. -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit The universe is always one step beyond logic. -- Frank Herbert ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GInterfaces and API Stability
On Wed, 2007-11-14 at 12:18 +0100, Murray Cumming wrote: On Wed, 2007-11-14 at 10:50 +0100, BJörn Lindqvist wrote: On Nov 14, 2007 7:54 AM, Kalle Vahlman [EMAIL PROTECTED] wrote: Matthias is right IMO, if you need to limit the additions of GInterface methods for C#, it should be done by the binding. Of course, if this is a more general problem, *then* it might be approperiate to refrain from adding interface methods in stable series. But it doesn't seem to be so. Lets say GTK+ 2.14 adds the function gtk_ibar_fiddle_foo() to the interface GtkIBar. If I use the GtkIBar interface I except the gtk_ibar_fiddle_foo() method to be there. If a method in another library compiled against GTK+ 2.12 returns a new GtkIBar object then the gtk_ibar_fiddle_foo() method will not be present. The likely result is a segfault in my program when I call gtk_ibar_fiddle_foo(). I guess that new vfuncs are usually tested for NULL before being called. Actually, I'd expect this for all vfuncs. In general, I'd expect the interface to adapt to not having its new vfuncs implemented. C can do that. That is not strictly needed. GInterface allows you to implement default fallback code for interface members. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GInterfaces and API Stability
I notice that there are no padding members in, for example,
GtkCellLayoutIface. Adding members therefore will change the
struct size which sounds like a clear ABI change to me.
Anyone who did
typedef struct {
GtkCellLayoutIface clif;
Bar baz;
} Foo;
is going to see random crashes when dynamically linked with a newer
gtk+. Not good. So even the C ABI was broken with
http://svn.gnome.org/viewvc/gtk%2B/trunk/gtk/gtkcelllayout.h?r1=12573r2=16976
GtkWidgetClass, on the other hand, has extension member to be used
for new signals. That does not suffer from the above.
Morten
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GInterfaces and API Stability
On Wed, 2007-11-14 at 09:30 -0500, Morten Welinder wrote:
I notice that there are no padding members in, for example,
GtkCellLayoutIface. Adding members therefore will change the
struct size which sounds like a clear ABI change to me.
Anyone who did
typedef struct {
GtkCellLayoutIface clif;
Bar baz;
} Foo;
Whyever would you do that? Such a struct would never be useful. All
actually used Iface objects (i.e. those that are registred with gobject,
etc) are dynamically allocated by the gtype machinery.
If you want to derive from an interface this is not how you do it (and
gobject doesn't allow interface inheritance). Instead you register a
pre-requisite on the to be inherited interface in your new interface.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GInterfaces and API Stability
On Wed, 2007-11-14 at 14:00 +0100, Alexander Larsson wrote: I guess that new vfuncs are usually tested for NULL before being called. Actually, I'd expect this for all vfuncs. In general, I'd expect the interface to adapt to not having its new vfuncs implemented. C can do that. That is not strictly needed. GInterface allows you to implement default fallback code for interface members. The problem with this capability is that it produces ambiguity in the API. If I am developing an application and I see that GtkCellLayout exposes a GetCells method, and I use a widget from libfoo which implements GtkCellLayout, but not the version of GtkCellLayout that exposes GetCells, I have to know that explicitly or my program is going to produce unexpected results. I don't see how a fallback implementation of GetCells can do anything but avoid crashes and return null. Using GInterfaces in this manner amounts to a mechanism which describes all the methods which might be implemented by an object. I'm not sure how useful that is to an application developer. -- Mike Kestner [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GInterfaces and API Stability
On Wed, 2007-11-14 at 17:23 +0100, Alexander Larsson wrote: In the case you describe GetCells is a pretty core part of the interface, and its clearly hard to not have it do much. However, that doesn't mean there are times when its useful. For instance, the default implementation of the method could call other methods on the interface, allowing you to add an extended method with a fallback to the previous unextended implementation. Which is probably no less ambiguous. If I'm calling an extended method that I expect to take more information into account than the basic method, but all it does it discard my additional constraints or preferences and use an unextended method, then how do I know what I'm really getting as a consumer? Another example is an interface that is a bit more generic, like GFile in libgio. You could add a new file operation that wasn't previously supported in a compatible way by having the default operation return a G_IO_ERROR_NOT_SUPPORTED. Code using this have to expect that errors can happen anyway, as some backends might not be able to implement all operations. I'm not sure I follow the example. I agree it's possible write an interface method in a manner to make it clearer that failure is possible. If you are saying that using this mechanism to provide optional interface methods is a good strategy, I would argue that providing a new interface to advertise the new capability is even better. You can make it clear at compile time what capabilities the object supports. -- Mike Kestner [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GInterfaces and API Stability
Alp Toker wrote: Matthias Clasen wrote: 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. This is totally missing the point. GObject interfaces exist to formalise a pattern of design by contract. Even if the C compiler doesn't catch and report incomplete interface implementations, that doesn't make it correct to ship code that breaks the rules. Your argument is analogous to claiming that it's OK to change property and signal names and parameters in an ABI-stable release because the C compiler won't notice that anything has broken. I think it's not about the compiler doesn't barf. It was a design decision to be able to always extend interfaces. The only thing GTK+ (talking about the concrete additions) has to handle non-implementations gracefully, which it easily can by NULL-checking before calling into the interface implementation. Even a default implementation can be added to be called if the interface function is not explicitly implemented. This reminds me of the Microsoft API Design video that Philipp van Hoof has blogged about. The speaker even claims that MS is extending their .Net-interfaces in similar ways. Regards, Sven ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GInterfaces and API Stability
On Wed, November 14, 2007 11:11 am, Mike Kestner wrote: On Wed, 2007-11-14 at 17:23 +0100, Alexander Larsson wrote: In the case you describe GetCells is a pretty core part of the interface, and its clearly hard to not have it do much. However, that doesn't mean there are times when its useful. For instance, the default implementation of the method could call other methods on the interface, allowing you to add an extended method with a fallback to the previous unextended implementation. Which is probably no less ambiguous. If I'm calling an extended method that I expect to take more information into account than the basic method, but all it does it discard my additional constraints or preferences and use an unextended method, then how do I know what I'm really getting as a consumer? People argue for a thousand years already about what an interface should mean. Different languages implement it in a different way (and some don't implement it at all, yet are still OO allright). What does it have to do with Gtk? Gtk interfaces can be extended, and the only requirement is not to break existing code, namely it should cope well with existing implementations of the interface which do not implement whatever new methods are there. So, Gtk breaks Gtk# because Gtk# developers assumed something wrong about Gtk behavior, too bad. Perhaps it's a bad problem, such that it's better to change Gtk to fix the problem, no idea, that's up to Gtk maintainers (it does happen). But it's in no way something like Gtk breaks holy principles of OO = Gtk breaks compatibility. For me personally there is no break here - just new API. But I don't do C# or Java, perhaps that's why. Another example is an interface that is a bit more generic, like GFile in libgio. You could add a new file operation that wasn't previously supported in a compatible way by having the default operation return a G_IO_ERROR_NOT_SUPPORTED. Code using this have to expect that errors can happen anyway, as some backends might not be able to implement all operations. I'm not sure I follow the example. I agree it's possible write an interface method in a manner to make it clearer that failure is possible. If you are saying that using this mechanism to provide optional interface methods is a good strategy, I would argue that providing a new interface to advertise the new capability is even better. You can make it clear at compile time what capabilities the object supports. And this should be argued on case by case basis, no? Like, is it better to extend GtkCellLayoutIface or to add GtkCellLayoutHaveGetCellsIface? Best regards, Yevgen ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GInterfaces and API Stability
Whyever would you do that? Such a struct would never be useful. It is a simple use of an existing type in the API. I can create my own instances of such a type, even if I cannot hand them off to anything GObject related. I could store signal handlers there, for example. Bottom line: a published type changed size. ABI break. I don't know if any applications out there do this and you probably don't either. But it is a valid thing to do. Maybe there should be an API/ABI stability documented that spells out the rules. Morten ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GInterfaces and API Stability
On Wed, 2007-11-14 at 17:40 +0100, Murray Cumming wrote: On Wed, 2007-11-07 at 14:58 -0700, Mike Kestner wrote: [snip] While it may not break C ABI/API to add a method to an existing GInterface, adding a method to an interface is a clear break in C#. You must implement all members of a C# interface, so code which previously compiled will break when a method is added to an interface. [snip] Can't you just choose not to wrap that vfunc in your C# binding? 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. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
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 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
Re: GInterfaces and API Stability
Am Mittwoch, den 14.11.2007, 17:40 +0100 schrieb Murray Cumming:
On Wed, 2007-11-07 at 14:58 -0700, Mike Kestner wrote:
[snip]
While it may not break C ABI/API to add a method to an existing
GInterface, adding a method to an interface is a clear break in C#.
You
must implement all members of a C# interface, so code which previously
compiled will break when a method is added to an interface.
[snip]
Can't you just choose not to wrap that vfunc in your C# binding?
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.
Wouldn't it possible to implement the GInterface as C++ class and add an
operator like this to the GObject wrapper class:
public:
GLib::RefPtrGFooInterface operator () {
return GLib::wrap_interface (gobj ());
}
?
--
Mathias Hasselmann [EMAIL PROTECTED]
http://taschenorakel.de/
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GInterfaces and API Stability
Matthias Clasen wrote: 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. This is totally missing the point. GObject interfaces exist to formalise a pattern of design by contract. Even if the C compiler doesn't catch and report incomplete interface implementations, that doesn't make it correct to ship code that breaks the rules. Your argument is analogous to claiming that it's OK to change property and signal names and parameters in an ABI-stable release because the C compiler won't notice that anything has broken. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GInterfaces and API Stability
2007/11/14, Alp Toker [EMAIL PROTECTED]: Matthias Clasen wrote: 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. This is totally missing the point. GObject interfaces exist to formalise a pattern of design by contract. Even if the C compiler doesn't catch and report incomplete interface implementations, that doesn't make it correct to ship code that breaks the rules. Your argument is analogous to claiming that it's OK to change property and signal names and parameters in an ABI-stable release because the C compiler won't notice that anything has broken. No, it would be analogous to *adding* new properties and signals (while maintaining ABI compatibility). Matthias is right IMO, if you need to limit the additions of GInterface methods for C#, it should be done by the binding. Of course, if this is a more general problem, *then* it might be approperiate to refrain from adding interface methods in stable series. But it doesn't seem to be so. -- Kalle Vahlman, [EMAIL PROTECTED] Powered by http://movial.fi Interesting stuff at http://syslog.movial.fi ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
GInterfaces and API Stability
I have been working on the 2.12 bindings for Gtk# and have noticed a stability issue for us related to GInterfaces. In Atk and Gtk, it seems there is no restriction against adding methods to stable GInterfaces. There have been numerous additions to the Atk interfaces while in stable mode. A GetCells method was added to the GtkCellLayout interface in 2.12. There may be more, I'm still working through the new API generated by our tools. We have recently added a GInterface registration capability to Gtk#, so this is going to be a real stability issue for us, going forward. We can wave our hands and pretend these previous additions weren't stability breaks since our GInterfaces were consume-only until now, but with implementation support starting in Gtk# 2.12, subsequent additions to existing interfaces will be problematic for us. While it may not break C ABI/API to add a method to an existing GInterface, adding a method to an interface is a clear break in C#. You must implement all members of a C# interface, so code which previously compiled will break when a method is added to an interface. 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. -- Mike Kestner [EMAIL PROTECTED] ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GInterfaces and API Stability
On Wed, 2007-11-07 at 20:47 -0500, Matthias Clasen wrote: On Nov 7, 2007 4:58 PM, Mike Kestner [EMAIL PROTECTED] wrote: I have been working on the 2.12 bindings for Gtk# and have noticed a stability issue for us related to GInterfaces. In Atk and Gtk, it seems there is no restriction against adding methods to stable GInterfaces. There have been numerous additions to the Atk interfaces while in stable mode. A GetCells method was added to the GtkCellLayout interface in 2.12. There may be more, I'm still working through the new API generated by our tools. We have recently added a GInterface registration capability to Gtk#, so this is going to be a real stability issue for us, going forward. We can wave our hands and pretend these previous additions weren't stability breaks since our GInterfaces were consume-only until now, but with implementation support starting in Gtk# 2.12, subsequent additions to existing interfaces will be problematic for us. While it may not break C ABI/API to add a method to an existing GInterface, adding a method to an interface is a clear break in C#. You must implement all members of a C# interface, so code which previously compiled will break when a method is added to an interface. 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 */ A bit ugly, but I tend to agree with Matthias that further narrowing the small set of places we can extend GTK+ while preserving ABI/API compat is not a good idea. - Owen signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GInterfaces and API Stability
On Nov 7, 2007 4:58 PM, Mike Kestner [EMAIL PROTECTED] wrote: I have been working on the 2.12 bindings for Gtk# and have noticed a stability issue for us related to GInterfaces. In Atk and Gtk, it seems there is no restriction against adding methods to stable GInterfaces. There have been numerous additions to the Atk interfaces while in stable mode. A GetCells method was added to the GtkCellLayout interface in 2.12. There may be more, I'm still working through the new API generated by our tools. We have recently added a GInterface registration capability to Gtk#, so this is going to be a real stability issue for us, going forward. We can wave our hands and pretend these previous additions weren't stability breaks since our GInterfaces were consume-only until now, but with implementation support starting in Gtk# 2.12, subsequent additions to existing interfaces will be problematic for us. While it may not break C ABI/API to add a method to an existing GInterface, adding a method to an interface is a clear break in C#. You must implement all members of a C# interface, so code which previously compiled will break when a method is added to an interface. 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. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
