[prev in list] [next in list] [prev in thread] [next in thread]
List: gtk-devel
Subject: Re: GIO API review
From: Alexander Larsson <alexl () redhat ! com>
Date: 2007-12-14 8:20:56
Message-ID: 1197620456.17059.13.camel () dhcp-208-188 ! arn ! redhat ! com
[Download RAW message or body]
On Thu, 2007-12-13 at 19:45 +0100, Richard Hult wrote:
> Mikael Hallendal wrote:
> > I just wanted to clarify though that it's not so much for technical
> > reasons I suggested that we namespace a bit more carefully.
> >
> > For example, if we plan to never use the GAsync infrastructure for
> > anything other than GIO there is a point to put it under the GIO
> > namespace as it shows where it belongs and what part of GLib it is
> > used for. It also means we can have GFooAsync later without the two
> > getting confused with each other. The same for GCancellable and
> > similar namespaces.
>
> And in this particular example, g_async_*, there is already a clash: we
> have g_async_queue_* right now, which is unrelated of course. A slightly
> longer name to avoid confusion here would be a fairly low price to pay
> in terms of typing. And I don't agree that it would be harder to read
> code with slightly longer names, on the contrary, at least when the
> added part is reasonably long. If it's clear what subsystem the function
> is related to, the developer doesn't have to stop to think.
I don't think this is really a conflict. The type name is GAsyncResult,
not GAsync. I don't think it is a problem to have different kinds of
types that start with GAsync, and its not like they are totally
unrelated (they are both about async tings). Its a similar situation to
e.g. GtkIconTheme and GtkIconView.
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic