[Bug 702960] gst_element_add_pad()'s pad parameter should be marked as transfer none

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=702960
  GStreamer | gstreamer (core) | git

Simon Feltman <s.feltman> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |s.feltman at gmail.com

--- Comment #11 from Simon Feltman <s.feltman at gmail.com> 2013-07-26 08:26:24 UTC ---
Basically if you call g_object_ref_sink or g_object_ref and manage an object
ref from within an APIs function, the annotation should be (transfer none). If
the API is intended to steal the ref from the caller (probably rare), the API
should be (transfer full).

I would limit "transfer floating" usage to return values from constructors
which return GInitiallyUnowned based objects. For function arguments, you
really should not care if the incoming object is actually floating or not, but
rather you probably want to manage your own ref to the object rather than steal
it from the caller. In which case you use g_object_ref_sink if objects are
GInitiallyUnowned based or simply g_object_ref otherwise.

Besides floating refs being a confusing mess, I think the nomenclature is also
part of the problem. IMO the terms the Python C API uses make more sense. For
returns you have "new ref" and "borrowed ref" [1] which in GI can be mapped to
"transfer full" and "transfer none" respectively. For arguments to a function,
the callee can "steal" or add its own ref, which maps to "transfer full" and
"transfer none" respectively.

Hope this helps!

[1] http://docs.python.org/2/c-api/tuple.html#PyTuple_GetItem

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.