[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 #5 from Xavier Claessens <xclaesse at gmail.com> 2012-04-03 06:49:06 PDT ---
I personally like (transfer none) for direct access of object's internal data,
like a lot of getters does. But I agree it is a bit dangerous since we can't
really return "const GObject" or "const GList*" or things like that.

>From my personal experience, I've (almost) never seen a getter call followed by
a modification of the returned value. It's always to iterate over it, like
foreach (account in am.get_valid_accounts()){}.

otoh, refcounted structs are cheap to dup, strings are safe to return as const,
and collections are always small (to the exception of
tp_connection_dup_contact_list). and probably GList is cheap to deepcopy with
slice allocator…

I still have that crazy idea that stuff like "return
g_object_unref_in_idle(obj)" would be useful to let a chance to caller to take
its ref while not introducing a leak if he does not care about return value.

And to finish, if we go with GList, please make it (transfer full/none), but
(transfer container) is just confusing IMO.

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