[gst-devel] Notes on the 0.9 API
Torsten Schoenfeld
kaffeetisch at gmx.de
Mon Nov 21 12:49:03 CET 2005
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
More information about the gstreamer-devel
mailing list