Re: GObject instantiation hopelessly overcomplicated??

[Tim Janik <timj gtk org>]

On Sun, 18 Jul 2004, James M. Cape wrote:

> Here's how the basic object creation sequence works:
>
> base_init() [only once]
> allocate the class structure
> class_init() [if it hasn't already been called for this class in this
> hierarchy]

i'm not sure what you mean with the "only once" for base_init(), and the
"hasn't already been called for this class" regarding class_init() definitely
sounds wrong. base_init() isn't called any less often than class_init (in fact
it's called for the class for which class_init() is called *and* for all
derived types). a more elaborate about the class creation process is at:

	http://developer.gnome.org/doc/API/2.0/gobject/gobject-Type-Information.html#GClassInitFunc

> constructor() [per-instance]
>     first, chain-to-parent, which:
>     --> allocates the instance structure.
>     --> calls instance_init()
>     --> calls set_property() for G_PARAM_CONSTRUCT properties
>     user-defined body of constructor()
> set_property() for non-CONSTRUCT properties.

i don't understand the fuzz about constructors here. there're only very
few resons to override the constructor, that is:
1) you want to implement a singleton where always the same object handle
   is returned from g_object_new (MY_TYPE_ALLOCATOR, NULL); (though that
   in itself is questionable behaviour, you're better off providing a API
   like MyAllocator* my_allocator_get_singleton (void); if that's feasible)
2) you need to setup object contents before g_object_new() returns, but
   after it has been (default-)constructed. usually, this kind of code
   can be fold into instance_init() or the set_property() implementation
   of a CONSTRUCT argument.

> When the user does not override the constructor() method, then the
> allocation method *appears* to be:
>
> base_init()
> class_init()
> instance_init()
> set_property()

after the class has been initialized, an instance is created through its
constructor like this:
1) calling the user type's constructor which then chains to (2)
2) allocating and 0-filling the object's memory
3) calling the instance_init() functions, starting from GObject, down to
   the most derived type (the user type) in this order.
4) calling set_property() for all construct and construct-only arguments.
5) here the constructor chaining returns and once the constructor finishes,
   GObject returns from g_object_new() (modulo setting some ordinary
   properties passed in to g_obejct_new() which could as well have been
   passed into a g_object_set() call next to g_object_new()).

> The destruction sequence is:
>
> dispose() [release any references to other objects]
> finalize() [free any additional data]
> class_finalize() [if no remaining instances, called once-per-class for
> dynamic types]
> base_finalize() [called only once for dynamic types]

again, base_finalize is called for the class it's introduced for and all
derived classes, analogous to the base_init() calls upon initialization.

> I can't really comment on whether or not it's too complicated for users,
> but everything in there has a reason why it exists, and changing it now
> would require breaking every object in existance, which would really
> suck :-).

you can be assured, there are no source incompatible
changes planned for GObject ;)

> Peace,
>
>     Jim Cape

---
ciaoTJ