Re: GIO API review

[Mikael Hallendal <micke imendio com>]

13 dec 2007 kl. 12.51 skrev Alexander Larsson:

Hi,

> On Wed, 2007-12-12 at 16:48 +0100, Mikael Hallendal wrote:
> > 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 31 number is a bit high, as a bunch of the listed things are
> internal only and some we could remove (as discussed in this thread,
> which is a good thing). Furthermore I don't think that e.g. having a
> GSimpleAsyncResult class grabs the whole g_simple namespace.
>
> However, it is true that there parts of the g_ namespace that are
> consumed by gio. However, that is true for any addition to glib or
> gobject too and yet we add names there. Also, even if we used a g_io_
> prefix we should avoid name conflicts anyway. It would be very
> problematic if we had both g_icon and g_io_icon types for instance.

GIcon is probably one of the examples where it makes sense to not have  
it under the GIO namespace.

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.

Without any namespace other than g_ it gives the idea that these  
"frameworks" are used for more than one subsystem (at least to me).

I don't think the "shorter name" argument is all that valid given that  
g_io_ is a very short namespace either. If that is the only reason I  
think we should change.

Also keep in mind, I'm not suggestion that *everything* should go in  
under g_io_, they would have to be weighted on their own merits and  
GIcon which is often used as an example might be one that doesn't make  
sense and have use cases outside of GIO.

GFile, GDrive, GVolume, GVfs are examples of namespaces that (without  
looking closer) strikes me as valid ones without the GIO. The  
namespaces themselves suggest that they have to do with the IO layer.

GAsync, GCancellable, g_push, g_pop, g_loadable, g_simple are examples  
of namespaces that would benefit from being under the GIO name spaced  
as they are too generic by themselves.

Best Regards,
  Mikael Hallendal

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