#50211 - would be nice to get rid of g_type_init()

[Owen Taylor <otaylor redhat com>]

First - some general considerations as to why init() functions
are harmful.

 - The need to call them is usually not obvious. They have
   nothing to do with what the user wants to do.

   (See. common FAQ about gdk_rgb_init())

 - When initializing multiple libraries, ordering is tricky, and if
   the functions have arguments (like g_type_init()) this problem is
   worse, because the library may well be initialized without
   its proper arguments.

   If every library really should have a init function, then 
   you need something like the init-function framework that
   Elliot came up with for GNOME libs 2.

In regards to g_type_init() in particular:

 - In the past, you made a statement along the lines of "Users shoudln't
   mind having to call g_type_init() because its the most fundemental
   library and essential to all operation.". 

   I think it works exactly the other way around. GType is mostly
   invisible to a programmer using higher level libraries based on
   GObject; a beginning GTK+ programmer won't even know that it
   exists.

   In general, the end-programmer will see GType based things
   as "just working". You call pango_context_new(), it creates
   a Pango context. Why on earth should you have to call
   g_type_init() first?

 - The debug flags argument to g_type_init() is just annoying.
   It means that g_type_init() has to be called _first_ from
   whatever place is parsing the command line, and it prevents
   libraries that don't want to have init functions (like Pango)
   from implicitely initializing GType as needed.

   It could easily be replaced by a g_type_set_debug_flags() function
   that the people who want to set GType debug flags can call at 
   program startup.

 - The points where g_type_init() need to be called are clearly
   defined. Basically, any function in GObject which doesn't
   take an already created GType object/structure and accesses 
   internal GObject data structures needs to check for initialization.

 - You've already added g_return_if_fail() statements for
   some of the above points. If we don't have g_return_if_fail()
   statements in all of then, then we have the
   mysterious-segfault-deep-inside-GObject problem. If we do
   add them for all places, then we might as well just add
   initialization in those places.

I see this as one of those cases where we can just make something
simpler and remove a burden from the programmer. And I think
we should do that.

If I've convinced you, I can make up the patch to implement the above.

Regards,
                                        Owen