On Mon, 25 Sep 2006, Emmanuele Bassi wrote: > On Mon, 2006-09-25 at 09:16 +0200, Alexander Larsson wrote: >> On Sun, 2006-09-24 at 14:33 +0200, Philip Van Hoof wrote: >>> On Wed, 2006-09-20 at 12:31 +0200, Alexander Larsson wrote: >>> >>> Hey Alex, >>> >>> Great that you are planning to redesign the VFS. >>> >>>> Here is my current GInputStream: >>>> >>>> struct _GInputStreamClass >>>> { >>>> GObjectClass parent_class; >>> >>> Using GTypeInterfaceClass here would make it much more easy to let >>> library and application developers implement the GInputStream interface >>> in a for-their needs suitable way. >> >> I'm well aware of interfaces. In fact my initial version used an >> interface for this. However, there are other aspects of the equation >> that has to be taken into account to. For instance, using a base class >> means you can inherit functionallity from the baseclass. > > Just a little note: GTypeInterface types really act more as "mixins" > than "real" interfaces in GObject, as they can effectively support a > default implementation inside their own definitions. > >> In fact, if you look at Java and .Net you will see that their streams >> are objects too, not interfaces. > > This happens mostly because Java and .Net do not have a native concept > of mixin/role types and only have pure interface types; so the only way > they have to define an abstract type with default implementations is to > create an abstract object. > > Anyway, there's no hard or compelling reason for using a GTypeInterface > instead of an abstract GObject.
except for multiple inheritance. i.e. with interfaces, you can write a MyInputOutputStream object, while with objects you usually need to fiddle with three different structures, a common data one, and two stream objects. (at least i think that was Philips point here) > Ciao, > Emmanuele. --- ciaoTJ _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list