On Wed, 20 Sep 2006, Alexander Larsson wrote:
> On Wed, 2006-09-20 at 14:30 +0200, mathieu lacage wrote:
>>>
>>>> 2) What is the signature of GDestroyNotify ?
>>>
>>> Its already in gtypes.h:
>>> typedef void (*GDestroyNotify) (gpointer data);
>>
>> ah. I forgot about this. Don't you think it might make sense for ease of
>> use to add a void *buffer arg and a GOutputStream * arg to the destroy
>> notification ?
>
> Nah, In typical real world cases these would already be in the user_data
> object. Say if you're reading a whole file async. It feels better to
> keep to the standard glib destroy notifier handling.
i have to agree with Mathieu here. not passing the original object handle
forces the user to keep tedious etxra data structures around.
imagine:
struct UserObject {
GOutputStream *stream1;
GOutputStream *stream2;
};
naturally, you'd pass UserObject* as gpointer data to the stream.
if your notifiers don't also contain the GOutputStream* handle though,
the user can't clearly identify stream1 vs. stream2 though, so he'd have to
resort to creating helper structures:
struct UserObjectOutputStreamCallbackData {
UserObject *user_object;
GOutputStream *stream:
};
and allocate/pass/free this instead.
both APIs are possible, it's just that passing the original stream handle
along makes life way simpler for the callback implementer. (though passing
around a buffer handle is not useful i think, it wouldn't even match all
asnyc ops).
(not providing GOutputStream, but just data, would be a bit like eliminating
the instance argument from signal handlers and force people to pass it along
as part of the user_data passed in to g_signal_connect() ;)
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Alexander Larsson Red Hat, Inc
> [EMAIL PROTECTED] [EMAIL PROTECTED]
---
ciaoTJ
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
