Re: Plans for gnome-vfs replacement
- From: Alexander Larsson <alexl redhat com>
- To: Tim Janik <timj imendio com>
- Cc: "gnome-vfs-list gnome org" <gnome-vfs-list gnome org>, "gtk-devel-list gnome org" <gtk-devel-list gnome org>, mathieu lacage <Mathieu Lacage sophia inria fr>, Paolo Maggi <paolo gnome org>, Paolo Borelli <pborelli katamail com>
- Subject: Re: Plans for gnome-vfs replacement
- Date: Mon, 25 Sep 2006 13:17:49 +0200
On Mon, 2006-09-25 at 12:47 +0200, Tim Janik wrote:
> On Mon, 25 Sep 2006, Alexander Larsson wrote:
> > 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.
The main thing I have against this is that it litters the namespace with
lots of type declarations for various types of seldomly used destroy
notifiers.
Anyway, this is clearly not the most important issue atm. :)
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl redhat com alla lysator liu se
He's an otherworldly Amish rock star with no name. She's a cynical insomniac
college professor trying to make a difference in a man's world. They fight
crime!
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]