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

[Tim Janik <timj gtk org>]

On Tue, 2 Sep 2003, Owen Taylor wrote:

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

looking at class_add_interface(), it does have an extra
check for the type the interface is being added to to be an
instantiatable type. but yes, technically we could add interfaces
to enum claases if we removed a couple checks. that'd be of limited
use i guess, the but the actual oddball in that, if you want it
pointed out is that enums have classes, not that classes can have
interfaces.

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

aha.

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

well, there's a point in accessing object classes, to retrieve data
and call methods/signal handlers. for enums, the data argument still
holds. the same is true for interfaces, but for the default interface,
there're about _0_ uses.
well, other than using it's pointer to implement
g_type_interface_list_properties(), which relies on all properties being
added to the default class btw. that's probably true for all sane interfaces
uses, but it should be added to the docs then, so properties aren't added
in the class-iface-callback.

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

---
ciaoTJ