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

[Chris Mungall]

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?

Should this be consolidated in CollectionI? On the dev branch?

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

nice

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.

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