[Dynamite] Inheritance
Ewan Birney
birney@ebi.ac.uk
Wed, 8 Mar 2000 17:16:49 +0000 (GMT)
On Tue, 7 Mar 2000, Ian Holmes wrote:
> Also -- under what circumstances is an interface method "virtual" in the
> C++ sense (i.e. dynamically bound)?
[BTW - apologies for the C++ snipe. It is just that ... well... you really
want a language that understands inheritenance to get this right, and we
have no decent nice language that satisifies all the requirements].
I think this will require some playing with it to shake it out. (ie, we
have to get our feet wet. I suspect I have done the most "inheritance"
type stuff with C in both GTK and CORBA interfaces, so I am most at home
here). Some points:
a) In some sense the interface definition just defines the headers.
How we deal with the implementation is up to us - the only requirement
that the interface has is you can call Base methods on Derived classes.
Ie there should be cases where you get a pointer and you don't know
whether it points to a base or a derived class.
As we generally want to type them somehow, this generally means some
casting to void implicity or explicitly casting to the Base class pointer.
Most people just go for the cast to void. GTK has an extra field and
macro system to typesafe this. Your milage may vary here....
- In CORBA all functions are "virtual" in the C++ sense. Everything is
done with pointers to functions and you can intercept this cascade of
pointer to function calls at a variety of points, the most common
being the end point where you actual provide the method. This results
in alot of quite tedious bioler-plate in the implementation code.
- We don't have to do this, but for some things, eg, LightSequence and
DatabaseSequence we know we want to plug different implementations behind
them, so these are definitely starting as fully vf style tables. I
volunteer to write this...
- For things where we know that we are providing the only implementations,
we can do something more like Ian suggests, with wrappers to functions
to provide the downcasting... as long as this works out that the
"calling the base class signature on the derived class gives the correct
answer". If the Base class struct is the first element in the dervied
class struct I believe this will work out.
- We can put fully "static" methods for things we are sure of. Later on
we are allowed to change the implementation, and because all inter-module
calls are only via the public headers, we only have to look inside the
module to check this will work...
Re: Constructors. Very common in IDL to have a
module {
// blah blah
interface Factory {
MyObject MyObject_construtor();
}
}
etc. It just moves the constructors out into one interface.
>
> This is confusing me a bit.
>
Easier once you seen it done. Wonderful when you rewrite things, recompile
one library, relink, and everything works *fine*.
> --
> Ian Holmes .... Howard Hughes Medical Institute .... ihh@fruitfly.org
>
>
>
> _______________________________________________
> Dynamite mailing list - Dynamite@bioperl.org
> http://www.bioperl.org/mailman/listinfo/dynamite
>