On Mon, 25 Sep 2006, Murray Cumming 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.
>
> 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.
there is no need for programming languages to present this in their
wrappers. it just means that interface implementors can opt to not override
an interface method and still get common default behaviour. if you want to
translate this to C++, it's simply:
virtual base_class_method() {};
instead of
virtual base_class_method() = 0;
> Murray Cumming
---
ciaoTJ
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
