Re: GIO API review

[Alexander Larsson <alexl redhat com>]

On Wed, 2007-12-12 at 16:53 +0100, Murray Cumming wrote:
> On Wed, 2007-12-12 at 16:37 +0100, Alexander Larsson wrote:
> > > >> GAsnc*        -> GIOAsync*
> > > >> G*Stream      -> GIOStream*
> > > >> GIcon         -> GIOIcon
> > > >> G*Icon        -> GIOIcon*
> > > >> GCancellable  -> GIOCancellable
> > > >> ...
> > > > 
> > > > I strongly oppose this. 
> > > 
> > > I personally prefer the naming Mitch suggests. I know from the name
> > > which sub-library the API belongs to in GLib.
> > 
> > I don't think this is something that is all that important when you
> > actually use the API. It certainly isn't so important that its worth
> > (methaphorically) punching you in the face every time you read or
> > write
> > the symbol.
> 
> If these are are all about IO and/or generally meant to be used
> together, I would also like them to share some namespace. If glib
> doesn't do it then I'll probably do it when I wrap them in glibmm. But I
> love namespaces.
> 
> If they are likely to be used separately, if they are generally meant to
> be self-contained then I'd be happy with just g_.

They are not only about I/I really. I'd like to think of them as part of
the "glib module", but for technical reasons (glib doesn't link to
gobject) they can't be in libglib.so. 

Now, some objects are clearly I/O related, but many are just
peripherally related to I/O and show up in the API because they are
required to express the other interfaces (like, files can have icons, so
we need an icon type, but it can't go in libglib, so it must go in
libgio). 

If we add things like GSettings to libgio (to avoid adding yet
more .so's) then things look even more weird. GIOSettings?