Re: instance-private-data issue

[Owen Taylor <otaylor redhat com>]

On Wed, 2003-08-06 at 08:33, Tim Janik wrote:
> On 5 Aug 2003, Owen Taylor wrote:
> 
> > On Tue, 2003-08-05 at 04:00, Mathieu Lacage wrote:
> 
> > > > The other advantage of the "bloat GTypeInstance" approach is that
> > > > this may not be the only problem of the form "G_TYPE_FROM_INSTANCE()
> > > > produces unexpected results in instance_init()".
> > >
> > > My personal god (namely Darin) would laugh at me if I tried to justify a
> > > patch with a sentence including the word "may".
> >
> > I, or you, can easily construct *artificial* examples of this problem.
> > I don't think anybody expects the current behavior. I think most
> > people would be shocked at what result you'd get if you put
> 
> the current bhaviour is indeed very expected, it's even documented in
>   http://developer.gnome.org/doc/API/2.0/gobject/gobject-GType.html#GInstanceInitFunc

What's documented is the that the class structure is different.
For those who know how G_TYPE_FROM_INSTANCE() is implemented,
that will makes it obvious that g_type_name_from_instance() will
give you the name of the parent class. For the other 99% of the
people using GTK+, it is very much unexpected.

> and FYI, i dug out up the original email that motivates
> the way we initialize classes:
>   http://www.gtk.org/~timj/init-type-bug-1998.email

While I didn't look up the email, I certainly did look up the
changelog entries. Yes, I know that it wasn't a random change.
I still don't have to agree that it was the best way to do things.

> >  g_print ("Creating a new widget of type %s\n",
> > g_type_name_from_instance (widget));
> >
> > into gtk_widget_init(). But I don't know of any real examples where it
> > is a problem other than than this one, so I said "may".
> >
> > When considering a couple of courses of action, considering all possible
> > upsides and downsides is important. Sometimes this upsides and
> > downsides involve a bug in bugzilla that someone encountered
> > last week. Sometimes they involve thinking about bugs that someone
> > *might* encounter next week. The first get more weight, but
> > ignoring the second is silly.
> 
> we have our class initialization in place now for more than 5 years without
> encountering any major problem. furthermore, we mimick the way other major
> languages initialize their classes.
> so at this point, i don't think it makes much sense to speculate about
> future problems with the way we do class initialization and make it
> sound like it's going to fall apart in the next few minutes.

Please don't get distracted by an irrelevant footnote, which said
exactly that this is somethign that can't be changed.

Regards,
						Owen