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

[Owen Taylor <otaylor redhat com>]

Following up here for completeness...

On Fri, 2004-01-09 at 21:47, Tim Janik wrote:
> On Fri, 9 Jan 2004, Owen Taylor wrote:
> 
> > While, in general, I'd have done it a little differently (simpler)
> 
> simpler? i doubt you can show me a way to make it much simpler on the
> macro user, though i'd apprechiate if you did.
> but if instead you mean you would have made the macro itself simpler
> (as e.g. the pango macros are), then that'd mean that object
> implementations with your version stay more complicated, which i
> find hard to see as a plus.

I mean, do less stuff. I think magic like defining parent_class
and prototyping the init functions makes things essentially
harder to understand ... sure, there is less code, but there
is more magic. And magic is bad. (Documented magic is still
magic.)

But anyways, that's just a philosophical thing ... not a
major objection.

> > what you have basically looks good, with two caveats:
> >
> > - being able to define multiple types in one file is, I think,
> >   very important.
> 
> that beahviour is preserved. first, we're talking about a
> convenience API here, so even if i screwed up completely and
> none of you guys would notice before 2.4, there'd be no
> _reduction_ in functionality. second, there's a macro
> variant G_DEFINE_TYPE_EXTENDED() now that allowes you to
> specify the parent_class name.

Well, practically speaking, for me, it just means in places
where I'm defining multiple types per file (and the more
types you define, the more useful these macros are), I'll
have to #define my own PANGO_DEFINE_TYPE() which is just
like G_DEFINE_TYPE but with a better choice of parent_class
name...

> >   I don't think the macro should take a non-prefixed name like
> >   parent_class. If you want the magic parent_class setup, then
> >   I think it should be prefixed like 'gtk_entry_parent_class'
> 
> there's a detailed comment describing exactly what the
> macros define, and i believe matthias is just turning that
> into real docs, so if in doubt, the behaviour isn't all that
> magic to the user.
> 
> as for prefixing parent_class like gtk_entry_parent_class, you
> don't provide a rationale for that, and in a previous email
> to jody i pointed out that that's counterproductive for 89% of
> current parent_class u

The reasons for prefixing are:

 A) Defining multiple classes in one file just works. We get
    rid of an arbitrary "G_DEFINE_TYPE() can be used only
    once for source code file restriction.
 B) As a general rule, I don't think that if we have macros
    to define stuff, they should define stuff in the
    unprefixed namespace. E.g., your macro doesn't just define 
   'class_init' and 'init()'

The fact that 89% of the current parent_class uses use just
'parent_class' simply means that GTK+ started off doing things
that way and people copied. It adds only a few seconds to
the conversion of something to G_DEFINE_TYPE to rename the
parent_class variable.

> > - I don't really like G_DEFINE_TYPE_WITH_CODE as a name ...
> >   it isn't at all clear why you want 'code' there, what
> >   'code' you are allowed to add, or
> >
> >    G_DEFINE_TYPE_WITH_INTERFACES()
> >
> >   would, I think, make things a lot easier to read. Using
> >   the 'code' name makes people study the macro definition.
> 
> that's naming after a probably common but still specialized case,
> which is i didn't take for a good idea. additional code that may
> need to go into the CODE section would be calling any of:
> g_type_set_qdata();
> g_type_add_interface_dynamic();
> g_type_interface_add_prerequisite();
> bse_type_add_blurb (GType, const gchar*); /* there are more variants */
> and for the future, we can very well get things like g_type_add_private().

Oh well, people will just cut-and-paste-and-not-really understand
anyways; if I had a better name suggestion I'd fight harder. :-)

Regards,
					Owen