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

[Tim Janik <timj gtk org>]

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

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

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

> Regards,
> 					Owen
>

---
ciaoTJ