On Tue, 2013-03-26 at 11:30 +0100, Murray Cumming wrote: > Well, they are listed as "derived Interfaces", because they "require" > the GTlsConnection type. Or, in other words, it is a "Prerequisite". > See > the G_DEFINE_INTERFACE() lines. Looking at all these made me notice > some > similar things we should fix some time: > https://git.gnome.org/browse/glibmm/commit/?id=c43ced750b04b8ae0556e8dfe317a4dbb6da327f > > For GTlsConnection it's a bit odd, because GTlsConnection is not an > interface, though GTlsClientConnection and GTlsServerConnection are. I > guess the glib developers are aware of the oddness of this, having > consciously chosen to give their interfaces some default > implementation.
Some more thoughts: I think we generally only want to represent the "preequisite" as a C++ inheritance when it's an interface depending on an interface. When it's an interface requiring an actual type then it doesn't seem useful to us. For instance: * GtkActionAble requires GtkWidget (rather than the default GObject). We have a TODO to add Actionable as a base class of _all_ derived Widgets, because they _implement_ that base interface. * GtkAppChooser requires GtkWidget (rather than the default GObject) AppChooserButton derives from, and implements, GtkAppChooser. * GtkFileChooser requires GtkWidget (rather than the default GObject) GtkFileChooserDialog derives from, and implements GtkFileChooser. Now, TlsClientConnection (an interface) requires TlsConnection (not an interface), so we could choose to treat this like GtkFileChooser requiring GtkWidget. To decide, I think we need to see how the types are used polymorphically, if at all. But I don't actually see any use of any of these types in the rest of the API, so it's hard for me to judge. I am tempted to not wrap them for now. -- Murray Cumming [email protected] www.murrayc.com www.openismus.com _______________________________________________ gtkmm-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gtkmm-list
