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

Reply via email to