Re: Interface signals.

On 4 Jan 2001, Havoc Pennington wrote:

> Tim Janik <timj gtk org> writes: 

> I'm looking at converting GtkTreeModel now - what's wrong with just
> keeping a class struct around for interfaces, and calling class_init
> and class_finalize on that class struct, as we do for object classes?

probably nothing wrong with that, but interfaces as we currently have them
in glib are more modeled after C++ signatures than Java interfacesm and as
such you can't override interfaces of parent types either.

> It could even be useful to provide default implementations of some
> functions in an interface. For example, in GtkTreeModel, you can
> implement some of the methods entirely in terms of the other
> methods. So default implementations make sense, even though the base
> interface doesn't know anything about the instance struct.

we'll probably have something like that once GType supoprots overriding
of interfaces of parent types.

> The other advantage of this is that interfaces will work exactly like
> objects with respect to signals.

this is not so much a signal issue as more a question of modeling in general.
you're forgetting one of the cons though, that is that for every branch
an interface is being introduced, it's class structure gets duplicated per
type node contained in branch (downwards on from the node the interface is
being introduced for).

> Havoc


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]