> 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.
So this is then a bit like multiple inheritance (of implementations). That
should probably be avoided because it's not possible for some programming
languages to represent it in their wrappers. And because it's difficult.
>> 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.
Murray Cumming
[EMAIL PROTECTED]
www.murrayc.com
www.openismus.com
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
