[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 #11 from Xavier Claessens <xclaesse at gmail.com> 2012-09-03 10:50:41 UTC ---
I think we'll decide that we won't decide...

This could really be just left undefined and decided on a case-by-case. At
least now that we have annotations, we are sure that the transfer method is
well documented.

IMO the container isn't really important, we can live we inconsistencies, and
I'm clearly too lazy to fix existing code in either direction. The most
important is to keep related APIs convenient. For example
tp_connection_upgrade_contacts_async() is taking n_contacts + c-array, so it
makes sense for tp_connection_dup_contact_list() to return a GPtrArray instead
of a GList.

What I'm more concerned about is the get VS dup. I think getters generally does
not ref/copy the return value if it is in the internal format. If it is not the
same format, then a _dup_ naming makes it explicit, which is IMO a good thing.
I don't think we want to duplicate memory every time we get a value. Except for
the transfer-container corner case, I think the rule of get VS dup is already
well respected in tp-glib API.

In the end, I think the most important is to avoid subtle changes in our
high-level API. Changing a _get_ to suddenly return a ref is going to be make
app porting much more complex. So I'm open to renaming APIs from _get_ to
_borrow_ or _dup_ but NOT changing the behaviour of an existing _get_.

I would like to keep in mind that tp-glib-1.0 is not the perfect API as it
always should have been. But rather a better API given the historical constrain
we have. Let's not make it a long and painful porting. It has already be long
enough.

-- 
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.