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

[Tim Janik <timj gtk org>]

On Fri, 23 Jan 2004, Owen Taylor wrote:

> Following up here for completeness...

how's "for completeness" meant, you still advocate for
the changes below, despite the recent gtk release, right?

> On Fri, 2004-01-09 at 21:47, Tim Janik wrote:

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

ok, i admit, i have to agree on (B). come to think of it, it
doesn't make much sense to type prefix class_init and init
and parent_class not, except for the status quo.
you and jody seem to not really worry about those 89%, so i'll
go ahead and indeed make that change.

>
> Regards,
> 					Owen

---
ciaoTJ