[Bioperl-l] Bio::FeatureHolderI interface confusion

[Hilmar Lapp]

Since it's perl one thing I still don't understand about this sort of
rant popping up once in a while is, why can't we have the interfaces for
those who like them and those who hate them just ignore them mostly. Why
does this have to be a quarrel? Why can't different people have
different OO coding styles?

Your point about when and where are features returned that can nest is
certainly true. Note also though that what you guys are trying to do is
the first use case pushing this envelope. None of the SeqIO parsers will
produce nested features - so people don't necessarily missed out on that
yet. In fact we had people on the list asking why the list of
subfeatures is empty. I anticipate you guys to find more things that
aren't very sensible here.

My personal view is biased towards more interfaces as will be no
surprise. Interfaces in perl to me have nothing to do with compile time
whatever, they mostly provide for contracts. Classes change and expand
all too quickly, and I've experienced that people quickly forget what
was supposed to be the minimal set of methods you can expect to be
present. I also like contracts to demand only what they need to demand,
and flat features make perfect sense to me. I believe interfaces have
been quite useful e.g. in the SearchIO tree.

And yes, when I want to be sure in my code that a feature has the
ability to return nested features I ask whether it is a FeatureHolderI
and throw an exception otherwise. Doing so costs me exactly one line of
code. Not too bad in my personal view.

Why don't you make a proposal, state how much that's going to destroy
backward compatibility, list what we would gain from it in exchange,
identify who's going to refactor the codebase accordingly, and then we
vote on it.

Otherwise I'm having difficulty seeing the point.

	-hilmar

> -----Original Message-----
> From: Chris Mungall [mailto:cjm at fruitfly.org] 
> Sent: Tuesday, June 17, 2003 11:29 AM
> To: bioperl-l at bioperl.org
> Subject: [Bioperl-l] Bio::FeatureHolderI interface confusion
> 
> 
> 
> 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
> 
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at portal.open-bio.org 
> http://portal.open-> bio.org/mailman/listinfo/bioperl-l
>