Re: Chaining Up (GLib Tutorial Error)

[Yevgen Muntyan <muntyan tamu edu>]

Stefan Kost wrote:
> Yevgen Muntyan schrieb:
>   
> > Phil Lello wrote:
> >     
> > > According to the GObject tutorial, chaining-up in 
> > > constructor/dispose/finalize code should be handled as follows:
> > >
> > > static void
> > > b_method_to_call (B *obj, int a)
> > > {
> > >   BClass *klass;
> > >   AClass *parent_class;
> > >   klass = B_GET_CLASS (obj);
> > >   parent_class = g_type_class_peek_parent (klass);
> > >
> > >   /* do stuff before chain up */
> > >   parent_class->method_to_call (obj, a);
> > >   /* do stuff after chain up */
> > > }
> > >   
> > >       
> > Yes, a tutorial mistake.
> >     
>
> Why? The major difference is that app do this:
>
> static GObjectClass *parent_class = NULL;
>
> xxx_class_init (GstElementClass * klass)
> {
>   parent_class = g_type_class_peek_parent (klass);
>   ...
> }
>
> and later e.g.
> G_OBJECT_CLASS (parent_class)->finalize (object);
> to chainup.
>   
> > > (Unless there is something horribly wrong with my implementation of 
> > > _GET_CLASS...)
> > >
> > > This works fine until we create CClass, a direct descendant of BClass. 
> > > When CClass is using the default 'method_to_call' code, e.g. in 
> > > finalize, B_GET_CLASS actually returns CClass. parent_class is now 
> > > BClass, and 'method_to_call' invokes itself, leading eventually to stack 
> > > overflow.
> > >   
> > >       
>
> B_GET_CLASS should always give you BClass and never CClass imho.
>   

Maybe it should (have, eight years ago), but it doesn't. B_GET_CLASS
returns the class to which the object belongs, its actual class. So its
parent will be whatever parent class of the object is, not the parent
class of the class which is being defined.
So the code you posted here works, but it is totally different from the
tutorial code, and the tutorial has an error in code.
>   
> > Yes.
> >
> >     
> > > The solution I've used, and that I think should be in the tutorial is:
> > >
> > > klass = g_type_class_peek (MY_CLASS_TYPE);
> > >
> > > Should I submit sample code to reproduce / raise a bug, or is this email 
> > > sufficient? I can provide a patch to tut_howto.xml if wanted, but this 
> > > seems excessive for a 1 line change.
> > >   
> > >       
> > It'd be better to use G_DEFINE_TYPE in the tutorial, IMO. A nice
> > macro, saves you from many troubles.
> >
> >     
> You're very welcome to do it. Its planned for a long time. IMHO the current
> details explanation should stay there as well. What should be added is more
> something like : "no that you've read about the internals, this is how you can
> do it in practise and save typing".
>   

Um, I didn't mean to criticize or even make a useful proposal.
I only wanted to make sure it's understood that there is a bug in
the tutorial code, which should be fixed. And then I added my
smart-ass two cents about G_DEFINE_TYPE, since I am a smart ass.
You are right, it wouldn't be better not to explain the internals;
G_DEFINE_TYPE is really better in an additional section.

Best regards,
Yevgen