Re: [giomm] Why most methods are non virtual ?

[Murray Cumming <murrayc murrayc com>]

On Sun, 2008-07-13 at 15:44 +0200, Yann Cointepas wrote:
> Hi,
> 
> I am trying to find a way to extend GIO to support my own non standard
> directory-like and file-like C++ objects. I would like to create
> specialized implementations of Gio::File and corresponding classes
> (such as streams) for my objects. My own factory would return either a
> standard Gio::File from a Gio factory or one of my own Gio::File
> implementation. But I noticed that most of the methods of Gio classes
> are non virtual (in glibmm version 2.16.4). Does it mean that I cannot
> just derive Gio classes and redefine the appropriate methods to use my
> new object transparently ? If yes, can someone give me some hints on
> how to implement this kind of polymorphysm with giomm ?

Making something derivable takes more than just making all its methods
virtual. Some thought must go into which methods can sensibly be virtual
and how they are used polymorphically by other methods.

The C API does have some virtual methods (function pointers in the
structs) but we chose not to wrap these as C++ virtual methods because
we thought it unlikely that anyone would want to derive new Gio backends
using giomm.

You don't seem to want to implement a new backend, to provide access to
any new file system type. I don't think it would be very wise (even if
you could) to make giomm instantiate your derived Gio::File rather than
its standard (already derived) Gio::File instances just for the sake of
some application architecture. It seems like that would be interfering
with a hierarchy that already exists.

-- 
murrayc murrayc com
www.murrayc.com
www.openismus.com