[Bug 21097] proxy subclasses should support optional features

[bugzilla-daemon at freedesktop.org]

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

--- Comment #5 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-04-06 05:35:30 PDT ---
(In reply to comment #4)
> Weakref is only
> http://git.collabora.co.uk/?p=user/smcv/telepathy-glib-smcv.git;a=commitdiff;h=aad1b67b938328f830984329fc950e238c1f96f3
> right ?

Correct.

> +    gpointer magic;
> A comment explaining the semantic of this pointer would be good.

Yeah, I'll add one. It's just an arbitrary "magic number" to detect
use-after-free or whatever (and it makes the size of the struct a power of 2,
which is probably not harmful? I'm not sure how g_slice_new pads things).

> +TpWeakRef *tp_weak_ref_new (gpointer object, gpointer user_data,
> That's now how you do coding style :p

It is in declarations, unless you're enforcing a stricter policy for header
files than we currently do (which I wouldn't necessarily oppose). /Style on the
wiki is ambiguous, and vaguely in favour of your stricter policy.

> What's the rational of having a dup_object() and no get_object()? In most case
> the object will be the 'self' pointer of the object who started the async call
> so getting an extra ref on itself is not interesting and just add an 'extra'
> g_object_unref.

The rationale is that this is the safe way to do weak refs. As long as only a
weak ref is held, the object's last ref could be released at any time, by any
call into user-supplied code (notably, any signal emission!); temporarily
strengthening the ref fixes this.

I could add a get_object version with a big fat warning, but I fear that the
result of that would be that everyone used the get_object version regardless of
what the documentation said, and had hidden use-after-frees...

(The other way to do this would be some sort of GClosure-based magic around the
callback, but that makes it awkward to use with existing callbacks.)

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