Re: #107397 (Re: type_info macro generation ...)

[Tim Janik <timj gtk org>]

On Fri, 9 Jan 2004, Jody Goldberg wrote:

> On Fri, Jan 09, 2004 at 03:41:08PM +0100, Tim Janik wrote:

> > 3) instance_init(Instance *self, InstanceClass *real_class) implementations
> >    that need the real instance class as argument upon initialization of super
> >    types are not possible with G_DEFINE_TYPE() since it prototypes the
> >    instance_init() function without the extra class argument. from my
> >    experience, code using this feature is rare enough though to justify
> >    implementing get_type() from scratch.
>
> Why did you choose the prototype the init functions ?  Putting the
> G_DEFINE_TYPE at the bottom of the file remove this requirement.

i considered that, but that way we would have ended up with either two macros
or without the macros defining parent_class. and parent_class i definitely
wanted the macro to handle, because that's what user code (and even the
existing boilerplate macros) get wrong occasionally.

> > 6) G_DEFINE_TYPE() can't be used multiple times in a single C file, due
> >    to the multiple parent_class pointers clashing. if people really are
> >    defining lots of small objects in a single C file, they can cook their
> >    own macro like this:
> > #define MY_DEFINE_TYPE(TypeName, type_name, TYPE_PARENT) \
> >         G_DEFINE_TYPE_INTERNAL (TypeName, type_name, \
> >                                 TYPE_PARENT, 0, type_name##_parent_class, {})
> >    and then write code like:
> >    MY_DEFINE_TYPE (GtkGadget, gtk_gadget, GTK_TYPE_WIDGET);
> >    [...]
> >      GTK_WIDGET_CLASS (gtk_gadget_parent_class)->expose_event (...);
>
> I'd much rather see the parent class pointer named
>     'typename_parent_class'
>
> Admitedly a quick trawl through cvs produces
> grep '[_a-zA-Z]parent_.*=[:blank:]*g_' parent_calls | wc -l
> 181
> grep '[^_a-zA-Z]parent_.*=[:blank:]*g_' parent_calls | wc -l
> 761
>
> So although parent_class clearly outnumbers foo_parent_class by a
> factor of 4 its not a complete walk over either.  I frequently put
> related sets of objects into one file.  A current example would be
> for custom GtkAction types and their associated GtkToolItem.
> Frankly looking at the GtkAction and GtkActionGroup implementation
> there would be some benefit to merging them into one file to avoid
> exposing internals.
>
> Can you expand on what you see as the benefits to using an
> unqualified name.  Are you trying to minimize the cost of converting
> existing code ?

FYI, none of the existing boilerplate macros (in nautilus,
bonobo, gsf, libegg or eel) do prefix parent_class, they either
don't bother defining it or they even depend on it being "parent_class"
literally.

in effect, only 11% of the parent_class occourances out there [1] use a prefix.
G_DEFINE_TYPE() is a convenience macro meant to ease object implementations,
so it'd be somewhat counterproductive if in 89% of the cases, it forced users
to type a more elaborate version of parent_class than they'd normally do.

that being said, you still retain the possibility to use a simlpe type
macro in conjunction with a customized parent_class name, by means of
using the now renamed G_DEFINE_TYPE_INTERNAL().
it's just not G_DEFINE_TYPE() that gets you this behaviour.

> If we end up with something that uses parent_name then
>     G_DEFINE_TYPE_INTERNAL
> needs to be renamed to something like
>     G_DEFINE_TYPE_FULL or _REAL
>
> to avoid the implication that we'd be depending on an internal
> interface tha that might go away/change.

point taken, it's called G_DEFINE_TYPE_EXTENDED() now and properly public.


[1] the common case to use parent_class is for constructs like
    GTK_WIDGET_CLASS (parent_class)->expose_event(...); so i grepped
    the CVS HEAD modules for "parent_[kc]lass)" and got:
    $ find . -name \*.c \
      -exec grep "parent_[ck]lass)" {} /dev/null \; | tee out | wc
       7568   35031  728424
    $ grep "[a-z_]parent_[ck]lass)" out | wc
        815    3839   84995
    $ grep "[^a-z_]parent_[ck]lass)" out | wc
       6753   31192  643429
    which means that just 815/7568*100=10.77% of the parent_class cases
    use a name prefix.

---
ciaoTJ