Re: Fake inheritance in GDK

[Owen Taylor <otaylor redhat com>]

murrayc t-online de (Murray Cumming) writes:

> On Thu, 2001-10-11 at 17:05, Owen Taylor wrote:
> > 
> > murrayc t-online de (Murray Cumming) writes:
> > 
> > > I'm auto-generating C++ wrappers for GDK 2, and I've discovered some
> > > small difficulties:
> > > 
> > > GdkVisualClass is declared as this, in gdkvisual.h:
> > > 
> > > typedef struct _GdkVisualClass    GdkVisualClass;
> > > 
> > > But _GdkVisualClass is not defined anywhere. I think that it should, at
> > > least, be defined as 
> > > typedef struct _GdkDrawableClass    GdkVisualClass
> > > as has been done for GdkPixmap and GdkBitmap in gdktypes.h
> > 
> > GdkVisual is not a GdkDrawable:
> 
> Sorry, I mean it should be
> 
> typedef struct _GObjectClass    GdkVisualClass;

What good would that do you except allowing you to merrily segfault as
you tried to derive from GdkVisualClass and got the structure size
wrong?

It's intentional that deriving from GdkVisual is not possible,q and
should not cause any problems for gtk-- because you can never create
"new" visuals, you can get references to the existing visuals.

> >  http://developer.gnome.org/doc/API/2.0/gdk/gdk-visuals.html
> >  
> > explains what a GdkVisual is.
> > 
> > > Actually, I'd like to change all of these pretend derivations to real
> > > derivations. The C++ compiler can't tell the difference between
> > > GdkDrawable*, GdkBitmap*, GdkPixmap*, and GdkVisual* because they are
> > > all simple typedefs of each other. Would you accept a patch to do that?
> > 
> > No. Breaking every GTK+ program out there not allowed. :-)
> 
> I didn't think the there would be any source breakage, and possibly not
> even any binary breakage, because
> 
> struct GdkBitmapClass
> {
>   GObjectClass
> }
> 
> might look just like
> 
> typdef struct _GdkDrawableClass GdkBitmapClass
> 
> Of course I was only guessing.

Well, GdkBitmap is different because there actually is no such thing
as a bitmap, it's just an alias for GdkPixmap. I'd expect that in
language bindings this type would not exist. (Use of the GdkBitmap
type indicates that only depth-1 pixmaps are allowed, but there are
plenty of other places where we have runtime depth restrictions, so I
don't see creating a special type for this.)

Adding a real GObject type for GdkBitmap would cause a lot of
convolutions in the backend implementations for no real reason, and it
just doesn't make sense to me that depth 2,3,4,5,6,... pixmaps are all
GdkPixmap but depth 1 gets a special type.

GdkPixmap and GdkWindow actually are new GObject types deriving from
GdkDrawable.

Regards,
                                        Owen