Re: Plans for gnome-vfs replacement

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

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

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
                  alexl redhat com    alla lysator liu se


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]