Re: GIO API review
- From: Mikael Hallendal <micke imendio com>
- To: Alexander Larsson <alexl redhat com>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>, Michael Natterer <mitch imendio com>
- Subject: Re: GIO API review
- Date: Wed, 12 Dec 2007 16:48:13 +0100
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/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]