[Dynamite] Inheritance

Ewan Birney birney@ebi.ac.uk
Wed, 8 Mar 2000 07:53:54 +0000 (GMT)


On Tue, 7 Mar 2000, Ian Holmes wrote:

> Did we come to any conclusion about how to handle inheritance?

in the C mapping?

I have been thinking about this alot. For inheritance to work, you must
be able to call a base class function on a derived class. As we don't have
the luxury of a C front like program around, this has to resolved at
run-time, which is fine anyway, because we probably want run-time
implementation switches anyway. I think the sane way to do this - relying
on C structs being truncatable is:

   interface Base {
     string method_a(in int something);
   }

   interface Derived : Base {
     string method_b(in int else);
   }

In the .h maps to

   typedef struct Base_str * Base;
   typedef struct Derived_str * Derived;

   /* I propose this mapping changes */
   char * Base_method_a(Base b,int something);

   /* this is duplicated so people don't get confused, but
    * has the indetical meaning to calling method_a from
    * on a derived object via the Base_method_a call
    */
   char * Derived_method_a(Derived b,int something);
   char * Derived_method_b(Derived b,int else);


The issue is that

   Derived d;

   /* calling a base method on derived */
   Base_method_a(d,12);

has to work. The proposal is that we cast to void the pointers, ie
in the .h 

   /* prevents compiler warnings as we can cast to void * fine */
   char * Base_method_a(void * b,int something);
   char * Derived_method_a(void * b,int something);
   char * Derived_method_b(void * b,int else);

In the object_internal.h, the only way to solve this is to have:

   struct Base_str {
     (char *)(*vf_method_a)(int something);
     /* implementation specific data members */
   }

   /* this can be cast to Base_str* and call vf_method_a fine */
   struct Derived_str {
     (char *)(*vf_method_a)(int something);
     /* implementation specific data members */
   }

As in theory we never know what object might be used as a Base class
to what derived object, this argues that all methods have to be laid
out in virtual functions. In practice, as we are in control of the
mapping and the implementation, we can be selective about what we put
into vf functions.

I suspect if we put one method into a vf function, we should put all
of them in there. things like SingleModel I think could/should be
fully concrete.


This mapping is easier than the CORBA C mapping if you are interested. ;)



Yes - we are rolling our own C++ here. Annoying - yes - but so is
having a piece of code that only works on redhat linux 5.2....


> 
> -- 
> Ian Holmes  ....  Howard Hughes Medical Institute  ....  ihh@fruitfly.org
> 
> 
> _______________________________________________
> Dynamite mailing list  -  Dynamite@bioperl.org
> http://www.bioperl.org/mailman/listinfo/dynamite
>