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

[Lincoln Stein]

On Wednesday 18 June 2003 04:52 pm, Chris Mungall wrote:
> On Wed, 18 Jun 2003, Lincoln Stein wrote:
> > My Bio::DB::GFF::Feature class extends sub_SeqFeature() so that you can
> > specify a primary_tag type:
> >
> > 	@parts = $feature->sub_SeqFeature('Exon');
>
> sounds useful, but I'm worried about overloading existing methods with
> different behaviours. Maybe a different method name?

My reasoning was that the default behavior of returning all the subfeatures 
still applies when the method is called without any arguments, as per the 
interface.


> again maybe we should standardise on a method name convention that is a
> bit more explcit (regardless of whether the method is magic or not)
>
>  @exons = $feature->getlist_exon()
>  $exons = $feature->getlistref_exon()
>  $feature->add_exon($exon)
>  $feature->addlistref_exon([@exons])
>  $feature->remove_exon($exon);
>  $feature->removeall_exon;
>
> another argument in favour of magic methods is that it makes it easier to
> switch between lists (nice and convenient) and listrefs (more efficient)
> without massive dumb code.

Very reasonable.  Of course I prefer shorter method names!

Lincoln

>
> > 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.
>
> heh heh
>
> Or Ewan...
>
> I like perl magic but overriding CORE::isa() seems like it's asking for
> trouble...
>
> > 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
>
> _______________________________________________
> 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
========================================================================