On Mon, 25 Sep 2006, Alexander Larsson wrote:
> On Mon, 2006-09-25 at 13:00 +0200, Tim Janik wrote:
>> On Mon, 25 Sep 2006, 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. This makes it
>>> much easier to implement things, because we can do the fallback async
>>> wrapper in the base class, and it makes it much easier to do wrapping of
>>> streams.
>>
>> not taking side on the interface vs. object issue here. however note, that
>> you can provide default implementations for interfaces with GType, simply
>> by hooking up class function pointers in the class_init function passed
>> when registering the interface type, i.e. just like with object type
>> registration.
>
> How does this work in say a Java binding. There you can't specify that
> you implement an interface without having all the methods in the
> interface, and there is no way to chain up.
i really have no idea how the java gtk bindings work. but in any case,
a binding can't recognize if an object implements methods of an interface
itself or if the interface had default implementations already.
you're right that you'll get trouble implementing input/output streams
in java though, if it only supports chaining for object methods and not
interface methods (which GType explicitely supports).
> Furthermore, you might want to store some data in the parent object to
> handle the default implementation, and I'm not sure where you would do
> that in this case. g_object_set_data() seems a bit ugly.
g_object_set_data() is about the only thing you have available here.
the problem with object data and interfaces is really that your interface
has no way to hook into object construction or dispose, and you only get
finalize notification as an interface implementor by using g_object_set_data().
so if you start to keep significant state in an interface implementation,
you can try how far you get with g_object_set_data() but it's usually best
to move to an object at that point. (e.g. if you keep open sockets, it might
make sense to close them in dispose, and not only finalize).
so in that regard, C++ multiple inheritance is a win over GTypeInterface,
as it allows you to encapsulate implementation details better for interfaces,
by functioning beyond the need of per-object data in interfaces.
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> Alexander Larsson Red Hat, Inc
> [EMAIL PROTECTED] [EMAIL PROTECTED]
---
ciaoTJ
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
