GObject instantiation hopelessly overcomplicated??

[Ryan McDougall <NQG24419 nifty com>]

The more I learn about what both type system and GObject do to create
instances, the more I come to the conclusion that the way it works is
way too complicated. I cannot think of a theoretical reason why fairly
simple constructor semantics wouldn't work, so I'm pretty sure there
must be a good practical reason ... however I'm not nearly experienced
enough to know what that might be. Can someone explain it to me?

Specifically:

In class object instantiation, why does it bother copying memory from
parent object to final when it will run the parent object's base_init on
the final object anyways? base_init takes no parameter, so its kind of
like a default constructor, no? Then anything that could be set with a
memory copy could be set with base_init. The only think that *couldn't*
be set is anything that was done to the class after base_init, which
should hopefully only be class_init. So why should we have a class_init
at all? Because class_init takes a parameter? Then why doesn't base_init
take a parameter?

Why does GObject implement its own constructor on top of the
instance_init constructors? Worse of all it makes you manually chain up
the parent constructors. If GObjects have their own constructors, then
isn't instance_init basically redundant and useless? I know the GObject
constructor is there to support properties, but couldn't we give
instance_init a parameter and just be done with it?

As I've mentioned before, I'm writing a tutorial (the first part of
which was posted to this list), so if you answer me, you will be
answering a lot of other people too.

Assuming that there are very good reasons for why the system is where it
is, what advice should I give readers about which of the many init
places is appropriate for what init code.

This exercise has really made me appreciate just how much GTK+/GNOME
need a proper high level language. Its interesting for me to learn about
this stuff but 90% of application developers cannot be bother with this
much minutiae.

Cheers,
Ryan