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? _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list