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

[Tim Janik <timj gtk org>]

On 27 Mar 2001, Owen Taylor wrote:

> 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.". 

that's not quite what i said, and indeed it wouldn't be fully
accurate, e.g. g_mem_set_vtable() and g_threads_init() definitely
have to be called before g_type_init() is being used.
also libraries like gnome or gtk+ will call g_type_init() on
their own (and are documented to implement a C object system,
so this is fine).

if however you're writing C code that needs an object system, but doesn't
make use of gnome or gtk, and wants to use GObject, then yes, you will
have to call g_type_init().

>    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.

right, that's why gtk_init() takes care of initialization for him.
however a programmer that uses the GObject sytsem without using either
gnome or gtk+ is pretty unlikely to not know about having to call
g_type_init() (and btw, will trigger an appropriate warning pretty fast,
which goes along:
G_STRLOC ": initialization assertion failed, use g_type_init() prior
to this function").

>  - 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.

as gnome brokeness has shown over the last 2 years (for anyone who ran
gtk/gnome application with export GTK_DEBUG=objects), most apps will
need type system initialization prior to having the full command line
parsed, so now we don't support object debugging via command line args
anymore, but just export GRUNTIME_DEBUG=[objects|signal] as well as
specifying debugging flags at type system initialization time.

>    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.

i replied to that earlier in a private thread and you never got back to me.
the answer i gave there was:

	> I'm going to advocate that we get rid of this parameters and
	> have:
	>
	>  g_type_set_debug_flags()
	>
	> [ And maybe:
	>  g_type_parse_debug_string()
	>  g_type_parse_no_debug_string() ]
	
	there is no benefit at all in adding these functions.
	introducing g_type_set_debug_flags() that is only effective
	before g_type_init() is being called icreases the number
	of "special" functions that have to be called "before
	everything else" like the thread initialization stuff
	or the malloc vtable thing. as such, adding that function
	is even an inherently bad idea.

>  - 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.

i'm _not_ going to add magic installation calls to every gtype/gobject/gsignal
API entry point, for a couple of reasons:
- calling g_type_init() for the few programs that don't use gtk/gnome
  isn't much of a burden
- we'd have to add g_type_init() to pretty much every function in the
  gtype/gobject/gsignal API, since without that even plain g_return_if_fail()
  statements break.
- we can catch 98% of programs out there using the API without initializing
  the type system by warning from the type registration functions which
  we do now
- i can imagine better things to clutter all of my API functions with

>  - 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.

no, we won't add checks for _all_ of them either, catching 98% elaborately
is good enough for blatant documentation-ignorant API abuse.

> 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.

we have _much_ greater burdens to worry about than non-gtk/gnome programmers
needing to add a single line at the beginning of their programs which is
good documented and keeps us from adding magic initialization in >350 places
in gruntime and dependant libraries.

> 
> Regards,
>                                         Owen
> 

---
ciaoTJ