From gtk-devel Fri Dec 14 08:20:56 2007 From: Alexander Larsson Date: Fri, 14 Dec 2007 08:20:56 +0000 To: gtk-devel Subject: Re: GIO API review Message-Id: <1197620456.17059.13.camel () dhcp-208-188 ! arn ! redhat ! com> X-MARC-Message: https://marc.info/?l=gtk-devel&m=119762047220787 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