On Mon, 25 Sep 2006, Alexander Larsson wrote:
> On Mon, 2006-09-25 at 12:04 +0200, Tim Janik wrote:
>> 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.
>
> The actual operation callback for an async operation does of course pass
> both the stream and the user data. And it is always called, even on
> cancellation, so the destroy notifier isn't required. The destroy
> notifier is more of an extra freebie to make it simple to add a g_free
> or g_object_unref to free the user object. For a more complicated
> multi-stream setup I think you'd do the handling in the operation
> callbacks.
ah i see, that makes sense, as far as the operation callback is
concerned at least.
> Also, In your example above the extra structure isn't needed. One would
> just use different destroy notifiers for the two streams.
hm, different? you mean you'd encode whether it's stream1 or stream2 in
the destroy notifier callback implementation?
well, that breaks as soon as the user has a non-fixed number:
struct UserObject {
guint n_streams;
GOutputStream **streams;
};
as an anecdotal side note, one case where i originally went for just
having a single data argument in the destroy notifier, and later had
to extend the callback signature to also cover the original object due
to user requests was GWeakNotify.
in your case, i think it's pretty forseeable that passing the object
handle along with the destroy notifier _can_ be useful and is easy to
implement on the caller side. if it's lacking, it's really tedious to
substitute on the user side though, so it'd be best to go with a signature
like that of GWeakNotify from the start.
>> (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() ;)
>
> I don't think so. I.e. for an aync read the callback would look like:
>
> typedef void (*GAsyncReadCallback) (GInputStream *stream,
> void *buffer,
> gsize count_requested,
> gsize count_read,
> gpointer data,
> GError *error);
>
> This callback is similar to the signal handler. The destroy notifier is
> just gravy on top of it.
>
> If we're stretching our comparisons a bit here it would be more like
> having the GDestroyNotifier called for a hashtable entry also pass a
> pointer to the hashtable so that you can destroy the entry differently
> depending on which hashtable it was in. :)
ok, i buy that one. ;)
and frankly, if i were to review the addition of destroy notifiers to
the hash table API *these* days, i'd insist on passing the hash table
along, similar to the instance in GWeakNotify ;)
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> 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
