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

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Wed May 2 14:45:11 CEST 2012


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

--- Comment #10 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2012-05-02 05:45:11 PDT ---
It seems that we essentially have two proposals for next. Jonny and I think the
policy should be

* get means copy
* borrow (or peek or something) means don't copy
* other verbs mean copy
* dup is not a thing
* lists are GList with (transfer full)

while Guillaume and Xavier think the policy should be:

* get means don't copy
* borrow/peek is not a thing
* dup means copy
* other verbs mean (... what? current practice is usually copy)
* functions returning a list are always dup, and return
  GPtrArray with (transfer container) and a free-function

0.19 is similar to the latter, mostly from inertia.

We're generally only adding dup, not get, for new APIs, because this is the
only thing that can possibly be thread-safe, and also the only way we can
(preserve the ability to) return a newly-constructed thing instead of random
internal state. Keeping these called "dup_thing" means our g-i bindings are a
bit rubbish (Python authors have to call dup_thing() even though they shouldn't
have to care about the distinction), because "Rename to" currently only works
if the "overwritten" thing exists.

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



More information about the telepathy-bugs mailing list