[Bug 39189] [next] decide on a policy for transfer, naming and containers

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=39189

--- Comment #14 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2012-09-03 11:25:28 UTC ---
(In reply to comment #13)
> So from a pragmatic POV:
> 
>  - We have 867 _get_. AFAIK they are all[1] returning the internal
> pointer/value. That's too much to change.

Yes, I think you may be right. I'd have preferred to be consistent with GIO,
but as long as we're consistent within tp-glib (1.0), and assuming Jonny
doesn't want to veto it, I'm OK with being consistent with tp-glib 0.x instead.
It's certainly the lower-risk route.

>  - We have 9 _borrow_. That's small enough to consider renaming them to _get_.

If we do the "add in 0.19, deprecate, remove in next" dance, this can be pretty
unintrusive.

>  - We have 34 _dup_. I would consider that too much to change.

Yeah. In some cases we genuinely do need to copy the pointer, and in some cases
it gives us flexibility to change the internals.

I think we should err on the side of using _dup_ in new APIs, though: it would
be nice if telepathy-glib could become thread-safe one day, after we finally
eradicate dbus-glib.

>  * If the structure is a GPtrArray (or anything that knows how to free its
> elements) I would consider them as dup (AFAIK that's already the case, see
> tp_connection_dup_contact_list).

These have to be annotated as (transfer container) but I think naming them
_dup_ is fine, yes.

>  * GList is really the special case here. They are often _get_ (e.g.
> tp_account_manager_get_valid_accounts). 1) I surely do NOT want to change them
> to not dup the glist anymore, that would make crashes in apps badly ported.

Agreed.

> 2)
> I would be in favor of making them transfer full and rename to _dup_.

For the Account GList ones, let's add (transfer full) _dup_ in 0.19, then
remove (transfer container) _get_ in 1.0.

-- 
Configure bugmail: https://bugs.freedesktop.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.