[Bioperl-l] proposed change to Bio::SeqFeature::Gene::*

[Hilmar Lapp]

> -----Original Message-----
> From: Chris Mungall [mailto:cjm at fruitfly.org] 
> Sent: Tuesday, June 17, 2003 2:08 PM
> To: bioperl-l at bioperl.org
> Subject: [Bioperl-l] proposed change to Bio::SeqFeature::Gene::*
> 
> 
> 
> Are these classes in use yet?
> 
> One change I would like to make, which should have no effect 
> on code that sticks to the documented methods, is to change a 
> minor implementation detail.
> 
> Now if we have a feature type X containing a feature type Y 
> (for example, X=GeneStructure, Y=transcript), the accessor 
> code looks like:
> 
> package Bio::Seqfeature::Gene::X;
> 
> sub y {
>    return @{shift->{_y} || []};
> }
> 
> 
> If we change this to:
> 
> sub y {
>   return grep {$_->primary_tag eq 'y'} $self->sub_SeqFeature;
> }
> 

In fact this is how I started it. Then there was considerable objection
from the PBI camp in Saskatoon who wanted in Genquire stick arbitrary
primary tags on features. The result is in front of you.

I just recently said to Jason this whole hierarchy of objects needs to
be refactored. I'm glad about whoever takes this on in a serious effort,
as I was afraid this was going to remain on the core's shoulders. Chris
if you guys want to dig in here I think that'd be great as you'd have an
immediate use case to validate the result on. The present implementation
is much too complex, not very elegant, and the arbitrary primary tag
thing is just incompatible with the whole SO idea.

So, bottom line, go ahead with boldness as far as I'm concerned. I don't
think these modules are widely used.

	-hilmar


> And make corresponding changes to add_y() [which would also 
> rebless the feature into the required type]
> 
> Then I think the code will be both easier to maintain, keep 
> in sync with the Sequence Ontology. It will also allow code 
> that expects generic feature hierarchies to use these 
> classes. It will also greatly simplify mapping to GFF3 and chado.
> 
> I certainly don't want to go poking around these classes if 
> it might break someone's code though.
> 
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at portal.open-bio.org 
> http://portal.open-> bio.org/mailman/listinfo/bioperl-l
>