Re: GIO API review

[Mikael Hallendal <micke imendio com>]

12 dec 2007 kl. 14.59 skrev Alexander Larsson:

Hi,

> On Tue, 2007-12-11 at 17:48 +0100, Michael Natterer wrote:

> > A big issue is that GIO wastes namespaces massively:
> >   g_app, GAsync, g_buffered, g_cancellable, g_content, g_data,
> >   g_desktop, g_directory, g_drive, g_file, g_filename, g_filter,
> >   g_icon, g_input, g_io, g_schedule, g_cancel, g_loadable,
> >   g_local, g_memory, g_mount, g_native, g_seekable, g_simple,
> >   g_themed, g_unix, g_vfs, g_volume, g_win32, g_push, g_pop
> >
> > That's clearly too much and can be reduced. While these are not
> > strictly "namespaces" (the namespace is g_), they partly clash with
> > g_foos and g_bars we already have, or might need in the future. We
> > stronlgy suggest to use a common g_io/GIO prefix for all
> > functions/types in GIO.
> >
> > GAsnc*        -> GIOAsync*
> > G*Stream      -> GIOStream*
> > GIcon         -> GIOIcon
> > G*Icon        -> GIOIcon*
> > GCancellable  -> GIOCancellable
> > ...
>
> I strongly oppose this.
>
> While gio is a separate library these are all symbols in the glib
> module, and while it might be a problem at times we can handle any
> conflict issues (since we control both libs and release them  
> toghether).
> So, I don't think the problem with this is that bad. I mean, gobject
> doesn't call its symbols GObjectClosure, g_object_signal,  
> GObjectValue,
> etc, and this has not been a problem.

The big issue is that GIO wastes a lot (31) of namespaces for no  
purpose. While some might not make sense to put under the GIO  
namespace (GIOIcon might be one of these, I don't know), the main  
chunk of them do.

The examples you took from GObject are perfect examples of parts that  
are a fundamental and big part of the GObject library and got their  
own namespaces. I'm sure there are a bunch of those in GIO as well,  
however, we should really consider it several times when introducing  
new namespaces. Both for future and for people trying to use the  
library.

Best Regards,
  Mikael Hallendal

--
Imendio AB, http://www.imendio.com/