Re: GIO API review

[Alexander Larsson <alexl redhat com>]

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.

There is no actual technical problem with using the g_ namespace in gio
(as they ship in the same module we can avoid conflicts), the only
danger of having the gio symbols use the g_ namespace is that we fear
that this would give naming problems when we later add stuff to glib.
Name conflicts would mean we would have to choose other names than what
we might want, so we risk having to use worse names later. However, the
proposed solution is imho far worse as it involves making all the gio
names worse just to protect against the risk of having to use worse name
in the future.

I deeply disagree with you saying there is no purpose in using the g_
namespace for this. API design is to a very large degree about good
naming. And using the g_ namespace leads to better naming: shorter
names, no enforcing the "io" meme on types where it doesn't make sense,
and a greater emphasis that these are core glib types that you should
use instead of third party APIs. 

I think my essential problem with this is that gio is for all intents an
purposes part of the abstract "glib" module, just as much as e.g.
gobject is. The fact that technical reasons force it into a separate .so
should not affect how we reason about it. The types it introduces should
be thought of as core glib types.

> 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.

I just picked any random symbols in gobject. No symbols in libgobject
use any prefix other than g_ (all symbols are in the form of
g_desciption_of_type). I think this is correct, as its part of the core
API of glib, as much as I'd like to think the new libgio APIs are. 

Having some types in libgio have the g_io_ prefix seems even weirder,
then is not even a namespace for a .so file.