[Bioperl-l] Bio::FeatureHolderI interface confusion

[Lincoln Stein]

Things get pretty hairy when the feature and its subfeatures are in different 
coordinate systems.  If it's allowed at all, it should be discouraged except 
when it can't be helped.

I think some of the confusion has come from the idea that the relationship 
between a SeqFeatureCollectionSet and its elements is equivalent to the 
relationship between a SeqFeature and its subfeatures.  One is just a 
collection of features, related perhaps by a query, and the other is a 
subpart relationship that could be described by a controlled vocabulary.

Lincoln

On Tuesday 17 June 2003 04:58 pm, Chris Mungall wrote:
> On Tue, 17 Jun 2003, Ewan Birney wrote:
> > > 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 definitely agree they should retain the same coordinate system by
> default.
>
> Isn't this what applications such as gbrowse (which I'm pretty sure make
> use of feature containment hierarchies) expect?
>
> If people really wanted to, say, have exons contained by transcripts AND
> have the exon locations relative to the transcript, could they do this
> with remote locations? I think this is to be discouraged in general.
>
> > 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.
>
> Perhaps the easiest thing to do now is just add FeatureHolderI to
> the @ISA for Bio::SeqFeatureI, and document it?
>
> > 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.
>
> I think we can have both; Bio::SeqFeature::Gene::<type> can be a blessed
> 'view' over a containment tree.
>
> The advantage is that applications (again using gbrowse as the canonical
> example) can take these rich classes and have a decent default display for
> them without having to write a new glyph for everything.
>
> More on this in a seperate email....
>
> > 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
>
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at portal.open-bio.org
> http://portal.open-bio.org/mailman/listinfo/bioperl-l

-- 
========================================================================
Lincoln D. Stein                           Cold Spring Harbor Laboratory
lstein at cshl.org			                  Cold Spring Harbor, NY
========================================================================