Re: Plans for gnome-vfs replacement

[Tim Janik <timj imendio com>]

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