[gst-devel] Notes on the 0.9 API

[Torsten Schoenfeld]

On Mon, 2005-11-21 at 08:58 +0100, Stefan Kost wrote:

> > * gstchildproxy.h doesn't get included by default.

What about this issue?

> > * gst_child_proxy_[sg]et is badly named.  Since GstChildProxy is an
> > interface, these methods map to $thing->[sg]et in OO-ish language
> > bindings -- thus colliding with g_object_[sg]et.  Something like that is
> > okay if the interface provides the basic functionality of the object
> > implementing it.  Example: gtk_tree_model_get also maps to $thing->get,
> > but if you call the "get" method on a tree model, it's pretty likely
> > that you actually want gtk_tree_model_get instead of g_object_get.
> > Fetching data is more common than fetching object properties.
> As I see it, properties *are* the data an object manages. For C we decided to 
> not overly extend the parameter names.

Well, but would you expect to get gst_child_proxy_get if you called the
"get" method on a GstBin or a GstPipeline?  That's what happens if
language bindings wrap the interface as-is.

> >  This doesn't hold for gst_child_proxy_[sg]et though, IMO.  For the Perl
> > bindings, I renamed the methods to "[sg]et_child_property".
> > 
> The child_proxy has gst_child_proxy_[sg]et and gst_child_proxy_[sg]et_property 
> and this mirrors the behaviour of g_object_[sg]et and g_object_[sg]et_property.
> Thats why I think to named gst_child_proxy_[sg]et -> [sg]et_child_property in 
> the binding is not a good idea.

You're right, using the plural is probably better.

> What I can think of would be to havesuggest is:
> 
> gst_child_proxy_[sg]et -> [sg]et_child_propeties
> (gst_child_proxy_[sg]et_property -> [sg]et_child_property)
> 
> On the other hand the latter will probably not be exported ...

Sounds like a good suggestion to me.  I'm not holding my breath on a
change of this API.  The C names make sense to C programmers, and
language bindings can work around the problems.

-- 
Bye,
-Torsten