[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