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

[Jody Goldberg <jody gnome org>]

On Fri, Jan 09, 2004 at 03:41:08PM +0100, Tim Janik wrote:
> 2) type implementations are forced to provide instance_init()
>    as the instance init function is prototyped within G_DEFINE_TYPE()
> 
> i collected some data [1] from CVS to figure whether this would impose a
> noticable inconvenience. it turns out that in CVS HEAD we have about 1700
> uses of GTypeInfo, out of which:
> 90.18%	provide class_init and instance_init
>  6.16%	provide only class_init
>  3.64%	provide neither
> 
> so with G_DEFINE_TYPE() enforcing the implementation of instance_init()
> and class_init(), the effective penalty out of a 100 cases is:
>  3.64%	forces extra class_init() implementation
>  9.80%	forces extra instance_init() implementation
> 
> in other words, that is one empty instance_init() prototype per saving
> 10 get_type()-implementations. i think that's an accaptable trade off
> for avoiding class_init_function_name and instance_init_function_name
> arguments for G_DEFINE_TYPE() and being able to provide the prototypes
> automatically.

This wouldn't have been my first choice, but your stats are fairly
convincing.  My gut feel is probably skewed because when writing the
objects initially they frequently don't need instance_init, which
only gets added later.
 
> 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.

> 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 ?

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.