Re: GIO API review
- From: Alexander Larsson <alexl redhat com>
- To: Richard Hult <richard imendio com>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>, Michael Natterer <mitch imendio com>
- Subject: Re: GIO API review
- Date: Fri, 14 Dec 2007 09:20:56 +0100
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.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]