On Tue, 2013-03-26 at 11:50 +0100, Murray Cumming wrote:
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.
I see. I think I understand now. For an interface, most likely it will not do much good to derive from a type that it requires if that type is not an interface.
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.
I could find no examples either. I had tried to write my own (based on what the C API's TLS Overview description section explains) which I'm attaching, but I didn't get far (I only get an exception). I guess it's fine not to wrap these either until it is more clear how they can be used. -- José
Attachment:
main.cc
Description: Text Data