[gst-devel] Notes on the 0.9 API

[Stefan Kost]

Hi Torsten,

Torsten Schoenfeld wrote:
> * gstchildproxy.h doesn't get included by default.
> * 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.
>  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. 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 ...

Stefan