[gst-devel] Why wrapping GLib interfaces?

Murray.Cumming at Comneon.com Murray.Cumming at Comneon.com
Tue Oct 14 07:01:05 CEST 2003

> 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
> interface example:
> (note the prerequisite in the _get_type() function)
> (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:
> (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
murrayc at usa.net

More information about the gstreamer-devel mailing list