Re: Plans for gnome-vfs replacement

[Tim Janik <timj imendio com>]

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
>                   alexl redhat com    alla lysator liu se

---
ciaoTJ