[gst-devel] Why wrapping GLib interfaces?

[Murray.Cumming at Comneon.com]

> From: Ronald Bultje [mailto:rbultje at ronald.bitfreak.net] 
> interface-per-instance layer:
> http://cvs.sourceforge.net/viewcvs.py/gstreamer/gstreamer/gst/
> gstinterface.h?rev=1.3&view=markup
>
http://cvs.sourceforge.net/viewcvs.py/gstreamer/gstreamer/gst/gstinterface.c
?rev=1.3&view=markup
>
> interface example:
>
http://cvs.sourceforge.net/viewcvs.py/gstreamer/gst-plugins/gst-libs/gst/mix
er/mixer.c?rev=1.4&view=markup
> (note the prerequisite in the _get_type() function)
>
http://cvs.sourceforge.net/viewcvs.py/gstreamer/gst-plugins/gst-libs/gst/mix
er/mixer.h?rev=1.5&view=markup
> (note that the case/castcheck aren't the standard glib ones - instead,
> they're our per-instace-checkers)
>
> app example that shows why this is easy:
>
http://cvs.sourceforge.net/viewcvs.py/gstreamer/gst-sandbox/gst-mixer/src/mi
xer.c?rev=1.7&view=markup
> (note the if (!GST_IS_MIXER (..)) continue;, our *only* code to check
> for this - it's extremely easy)

This really does look like per-instance interfaces, and therefore
per-instance API. It may be easy for you to implement and use, but it's
still going to be a problem for language bindings. A C++ instance can not
decide at runtime what base classes it has. A Java object can not decide at
runtime which Interfaces it implements. Languages such as Python might be
able to do this, but it's always going to be hacky.

I don't see why Aggregation wouldn't work just as well here without
distorting the Gobject system.

Murray Cumming
www.murrayc.com
murrayc at usa.net