[Bioperl-l] Re: Bio::SeqFeature::FeaturePair, HMMER

[Ewan Birney]

On Thu, 14 Sep 2000, Hilmar Lapp wrote:

> As those subscribed to the guts list will have noticed, I changed the
> inheritance of Bio::SeqFeature::FeaturePair and
> Bio::Tools::HMMER::Domain.
> 
> The first one now inherits directly off Bio::SeqFeature::Generic instead
> of re-implementing SeqFeatureI in an incomplete way. The second now
> inherits directly off FeaturePair (because of the first change, it
> doesn't have to inherit off SeqFeature::Generic any longer).
> 
> Changed on both the main trunk and the branch. Tests run ok.


Just a warning Hilmar --- I feel this is somewhat of too big a change for
the branch. I realise that from your view that this could should "work ok"
and "passes tests" but over at Ensembl changes that "works ok" have broken
things --- meaning that I have a 2 day bug hunt to figure out what has
broken and why. This is very annoying for me. heikki's translate change
ended up breaking something *very* subtle in Ensembl, not obviously to do
with translate...


I don't want to have to maintain a separate "ensembl only" branch from
bioperl, but to be confident of this I need to know that branches are
going to maintain stability.

(I realise this is probably due to the fact that we branched 0.6 with too
many bugs first off, and ultimately this is my fault. Just be nice to
me...)


For better or worse we should try to keep changes on the branch to being
*just bug fixes*. I don't think this qualifies as a bug fix. 


This is, of course, fine for the main trunk, which is where all of this
should happen... 


 > 
> There are several issues:
> 1) When inheriting off an interface and a class implementing that
> interface, because of the poor support of Perl for OO-concepts calling an
> interface method results in an _abstract_death (or whatever the interface
> implementation does), because you can't really have abstract methods in
> Perl (the Perl compiler finds 'inherited' methods by first encounter: if
> that one actually is meant abstract by you, Perl won't know). Changing
> the order of inheritance solves this problem, but then why inherit off
> the interface at all?

if you do inherit off the implementation that has the interface, then I
guess additional interface inheritance is not needed. I don't think it
does much harm...


> 2) Implementing methods an interface requires with zero functionality is
> a bad idea: a caller or test-script won't notice immediately that he
> called something that is not supported by the module, but instead may
> experience subtle failures later on. So, if your module doesn't support a
> particular method the interface you're implementing requires, either
> don't supply them at all (usually the interface will catch calls by
> throwing an exception), or provide an implementation that throws an
> exception with an appropriate message. DO NOT implement that methods by
> just returning undef, zero, etc.
> 

There are times when I think returing zero/undef etc is sensible. It means
that this implementation is somewhat "crippled" but if zero/undef is a
*valid* thing to return then it is ok for an implementation to return it.

This happens quite a bit in the C extensions and other out-of-perl
experiences where some things are very hard to implement.


> 	Hilmar
> 
> -- 
> -----------------------------------------------------------------
> Hilmar Lapp                                email: hlapp@gmx.net
> NFI Vienna, IFD/Bioinformatics             phone: +43 1 86634 631
> A-1235 Vienna                                fax: +43 1 86634 727
> -----------------------------------------------------------------
> 

-----------------------------------------------------------------
Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420
<birney@ebi.ac.uk>. 
-----------------------------------------------------------------