[Bioperl-l] Bio::FeatureHolderI interface confusion

[Ewan Birney]

>
> 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

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
> http://portal.open-bio.org/mailman/listinfo/bioperl-l
>