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

David Block dblock at gnf.org
Wed Jun 18 10:30:15 EDT 2003


On Tuesday, June 17, 2003, at 04:23  PM, Hilmar Lapp wrote:

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

If I could just jump in here, :-)

We didn't have the SO at the time.  I think it's clear from both Mark's 
work and mine (Hilmar can vouch for me) that the Genquire people were 
not opposed to ontologies in principle - rather, we were ahead of the 
tools.  So Genquire required some flexibility, which can now be 
provided by SO and other ontologies.  Genquire can adapt to the new 
ontology-based structure of things.

Please break everything - Mark is paying a summer student to fix 
Genquire anyway :-)

And thanks, Chris, for your GenbankWhateverUnFlattener code.  Someone 
had to try, and Mark and I kept thinking about it.  We're happy to let 
you guys do it.

Back to my J2EE coding/lurking.

Dave
>
> 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
> >
>
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at portal.open-bio.org
> http://portal.open-bio.org/mailman/listinfo/bioperl-l
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3468 bytes
Desc: not available
Url : http://portal.open-bio.org/pipermail/bioperl-l/attachments/20030618/be2b4066/attachment.bin


More information about the Bioperl-l mailing list