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

[Lincoln Stein]

My Bio::DB::GFF::Feature class extends sub_SeqFeature() so that you can 
specify a primary_tag type:

	@parts = $feature->sub_SeqFeature('Exon');

Internally sub_SeqFeature essentially does a grep for features with the right 
primary_tag, except that the primary_tag has already been assigned to a hash 
structure so that it doesn't have to grep each time.

There's also an AUTOLOAD method that looks for methods that have an initial 
uppercase (which is the convention I use for magic methods), and implements 
the following:

	@parts = $feature->Exon;

where the call is delegated to sub_SeqFeature().

At one point, I had also overriden CORE::isa() so that you could do this:

	$parts[0]->isa('Bio::SeqFeature::Exon');

... but at that point I lost my nerve thinking about what Mark might say if he 
found out.

Lincoln



On Tuesday 17 June 2003 07: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.
>
> 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

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