Re: GObject instantiation hopelessly overcomplicated??

On Sun, 2004-18-07 at 01:39 -0500, James M. Cape wrote:
> base_init() is called exactly once -- it's useful for initializing
> classwide variables (e.g. a hash table of all the existing objects in
> that class) that should only be initialized once.
> class_init() is called once-per-class (and subclass) to add the required
> properties, signals, and method/signal overrides to the desired class
> structure, which will be different for every subclass.

I think you have base and class init inverted. I checked the source code
to make sure. :)

The part that I don't understand is why two functions are necessary, it
makes it unclear for the programmer where to put his init code. What
code has to run in class_init that can't run in base_init? There appears
to be no reason why, so thats exactly what I am asking for (a reason

You've also said nothing about why it copies the parent class over the
child class.

Similarly GObject's constructor instantiation (GObject is considered to
be the only way to make a decent classed type) renders totally redundant
instance_init, a good part of type instantiation, and therefore a good
part of GObject instantiation. It doesn't yet make any sense to me.

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

I'm not asking for a change, which would be practically very difficult,
for mostly aesthetic benefits (although it might be considered for the
3.0 time frame). What I want to know is why it is that way so I can
inform readers of my tutorial the reason for the madness, and therefore
where they should put their code.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]