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 anyconflict issues (since we control both libs and release them toghether).So, I don't think the problem with this is that bad. I mean, gobjectdoesn'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/