[Bioperl-l] Bio::FeatureHolderI interface confusion

[Chris Mungall]

I'm a little confused by the proliferation of interfaces in bioperl. I've
been tying my head in knots trying to figure out Bio::FeatureHolderI all
morning, and I'm pretty sure there is something seriously wrong.

>From my knowledge of the guts of bioperl, I know that any features
generated by one of the SeqIO::* classes will be Bio::SeqFeature::Generic
objects, and they will therefore implement Bio::FeatureHolderI

However, I'm not sure how that knowledge would be accessible to the
non-initatiated.

- Bio::SeqIO states that SeqI compliant objects are created

- the Bio::SeqI docs hints that Bio::SeqI may itself be a
Bio::FeatureHolderI, and it therefore implements the method
get_SeqFeatures()

- However, both Bio::FeatureHolderI and Bio::SeqI state that
get_SeqFeatures() returns a list of Bio::SeqFeatureI objects;
Bio::SeqFeatureI is NOT a Bio::FeatureHolderI. (This of course means that
Bio::FeatureHolderI is NOT necessarily recursive)

So it seems that there is no guarantee that anything returned from
Bio::SeqIO will implement Bio::FeatureHolderI. However, I am writing code
that assumes the features obtained from a SeqIO class is a
Bio::SeqFeature::Generic and hence implements Bio::FeatureHolderI. Is this
bad?

If it is bad, how is it possible to get hold of a feature that
implements Bio::FeatureHolderI? Other than rolling my own?

It seems that the easiest short term solution is to force Bio::SeqFeatureI
to implement Bio::FeatureHolderI

The 'correct' solution within the context of post-GOF OO design is to
create a new interface Bio::SeqFeatureThatIsAFeatureHolderI which inherits
from both Bio::SeqFeatureI and Bio::FeatureHolderI.

Bio::FeatureHolderI->get_SeqFeatures() would then return instances of this
new combined interface. (After all, Bio::FeatureHolderI isn't much use
unless it is recursive).

However, I think this 'correct' OO solution is just patching insanity with
insanity.

Personally, I would much rather see the swarm of interfaces and objects
stopped and rolled back.

In fact, I can't really see why we can't make do with just Bio::SeqI and
Bio::SeqFeatureI

(or even one class to represent both of these...)

Why not force every Bio::SeqFeatureI class to implement get_SeqFeatures()?
That seems to be the 'implicit' cryptic inheritance structure we have now.

What is the gain in proliferating interfaces?

One argument is that we might want 'lightweight' seqs or features.
However, this is a false argument since the memory footprint can be made
the same. I cannot think of any software engineering arguments beyond OO
dogma in favour of proliferating interfaces.

Perhaps if we were programming in a java straitjacket this would provide
us with some level of compile time checking. However, java methodology
certainly does not translate to perl. Most of bioperl would not compile if
ported directly to java (for reasons stated above - e.g., accessing
FeatureHolderI methods when not in a FeatureHolderI compliant object). It
seems perverse to mimic this whole compile time checking infrastructure
when no compile time checking is performed.

I think it also makes things easier for new users if the number of
classes/concepts they have to deal with is kept to a minimum.


--
Chris Mungall
cjm at fruitfly.org