[Bioperl-l] Bio::FeatureHolderI interface confusion

[Chris Mungall]

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