[Bioperl-l] Bio::FeatureHolderI interface confusion
birney at ebi.ac.uk
Tue Jun 17 23:56:34 EDT 2003
> 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
Music to my ears Chris. I also believe this. However, nested features or
not vs nested location models or not is a somewhat more mulling question.
Also - when features nest, what is implied about their coordinate system
(I would argue nothing - coordinates are always on the Bio::SeqI =
Bio::SeqI is the coordinate system). would you agree with this or want the
coordinate system to nest?
I'm happy to extend Bio::SeqFeatureI to have a get_SeqFeatures() and/or
get_sub_SeqFeatures(), indicate that the coordinate system does not nest
and remove the other "helper" interfaces.
I have to admit, I am against complex trees of SeqFeatures "meaning"
something, and would prefer people to build their own specific objects
(eg, Bio::SeqFeature::GeneStructure) to represet specific features, but
here we probably diverge in views.
Lincoln, Paul, Aaron and Jason probably all have views here...
> (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
More information about the Bioperl-l