[gst-devel] gst_element_connect et al naming

[David I. Lehn]

* Andy Wingo <wingo at pobox.com> [20021008 21:23]:
> On Tue, 08 Oct 2002, David I. Lehn wrote:
> > This requires code that would normally be written as:
> >   element.connect("sig", handler)
> > to be written in a rather awkward form:
> >   GObject.connect(element, "sig", handler)
> 
> This is an instance where, IMNSHO, the object-oriented model fails. An
> element connection involves *two* elements, neither of which is
> privileged. this function would make a lot more sense as
> gst_element_connect (foo, bar), which incidentally is how it works in c.
> if you want OO, try element.connect_to() or something.
> 

The first arg is more privileged isn't it?  It's the source.  Which
seems to work quite well in OO with more verbose naming like
e1.connect_to(e2) or e1.connect_to_element(e2).  And that reads better
in C too doesn't it?  gst_element_connect_to_element(e1, e2)?  (which I
guess is getting rather verbose... which is no doubt why gobject made a
shortcut name that's causing this issue)

In any case, GObject is a parent class of GstElement and has a connect()
method which is used for signals.  People new to the GStreamer API with
a OO background will probably at first glance just assume that our
connect() is overloading some signal functionality from the GObject
connect().  My thinking is it would be nice to avoid confusion on the
issue and make OO language bindings easier to use in the process.  I
could just rename the binding for gst_element_connect() but it would be
nice to conform to the C naming.


> > Comments?  Is there more API with similar overloading?
> 
> considering g_object_connect is merely a convenience routine for things
> defined in gsignal.h, i would tend to see the problem in the gtk signal
> code and not in gstreamer. not that i think there's a problem ;-)
> 

I too think the GObject naming should be more specific.  But that won't
be changed.  I guess it could be argued that using just "connect" in our
naming is just as bad a policy.  I'm all for a slight bit more verbose
names to make code clearer.

-dave