Re: Another iteration of the properties-on-interfaces patch

[Owen Taylor <otaylor redhat com>]

On Tue, 2003-09-02 at 14:15, Tim Janik wrote:
> On 22 Jul 2003, Owen Taylor wrote:
> 
> > On Mon, 2003-07-21 at 21:51, Tim Janik wrote:
> 
> > With the current proposal, making interface introspection
> > in gtk-doc is the same as for signals ... you just have to order
> > things right.
> >
> > With your proposed interface, you'd have to hunt through all the
> > classes to find one that implemented the interface.
> >
> > It's pretty clear to me what the *right* fix is:
> >
> >   Make interfaces "classed" by having the class_init() function,
> >   if supplied, be used to create a prototype class that
> >   is copied for instances of those interfaces, rather than
> >   using g_new0().
> 
> a "classed" type as gtype.[hc] interprets it is something that
> has a single vtable and that interfaces may be added to, so
> interfaces can't in that sense become "classed".

You can add interfaces to an enumeration??? I always thought
of "classed" as being basically:

 Has a structure holding additional information about the
 type that can be obtained with g_type_class_ref()

I thought the ability to add interfaces came with being
INSTANTIATABLE. But in any case, whether or not the CLASSED
flag is set isn't really my concern, it basically just seemed
to me expected that if

 The default vtable was passed to class_init for interfaces

then:

 Calling g_type_class_ref() on interfaces will give you
 the default vtable back.

> > Advantages:
> >
> >  - Makes interfaces more like classes, so less confusing
> >  - Fixes the ugly base_init() hack for signals and properties
> >  - It might even be occasionally useful to provide default
> >    implementations.
> 
> i've committed this to CVS now, in gtype.c i've been calling the
> newly created vtable that all other interface vtables are being
> copied from the "default vtable" (thus IFaceData has dflt_init,
> dflt_finalize etc. now).

I'll buy a vowel. :-)

> however, i'm _not_ exposing the default vtable through g_type_class_ref(),
> for one because i don't want to make that function anymore complicated
> than it already is, and secondly, an interface is simply not a class
> the way GType has it.

I don't see a big reason to make the function more complicated - it's
just:

 if (G_TYPE_FUNDEMENTAL (type) == G_TYPE_INTERFACE)
   return ref_default_vtable()

more or less.

> we badly need a few plugins btw, to test dynamic class implementations,
> interface implementations, interface-for-class implementations,
> derivation-combinations thereof and default-vtable use all throughout
> base-init, init, finalize and base-finalize.

I'd like to see the GObject test suite extended a lot. My intent
with testifaceinit.c was to try and create a test case that:

 - Tested one thing (ordering of interface inintialization)
 - Was as small as possible
 - Ran silently on success

So, more of a unit test in the classic sense of the terms. I think
it might make sense to have a separate subdirectory for GObject
tests so we can add new ones as we think of new things to test
and have 'make check' test that we don't get regressions.

> > I think that can be done compatibly,. *However* it's also a major
> > change, and doubtless has all sorts of unexpected side effects
> > throughout gtype.c. Not something I wanted to try and tackle.
> >
> > Without making that change, I think taking an interface class
> > here is really too ugly.
> >
> > I suppose if we simply *planned* to make the change but didn't
> > actually to it for GObject-2.4, it might be OK to accept the
> > temporary ugliness.
> 
> well, the remaining question here is if you really want to expose
> the default vtable of an interface to the user. if so, we should add
> an interface specific ref/unref pair for that (currently, a default
> vtable won't even be created untill a class implementing that interface
> is actually initialized).

If you want g_type_interface_list_properties() to take a vtable, then
it needs to be possible to use the default vtable and to get the default
vtable without initializing any classes.

I don't really understand why we can't view the default vtable as
the "class" of the interface:

 It is a structure with a 1 <=> 1 correspondance with the GType
 with the GType as the first member

But if you think g_type_interface_ref_default_vtable() is necessary,
than that's better than having nothing.

Regards,
						Owen