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

[Tim Janik <timj gtk org>]

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.

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

>   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 uses, so i'm not favouring that.

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

>
> Regards,
> 						Owen
>

---
ciaoTJ