[Bioperl-l] Re: Bioperl-l digest, Vol 1 #200 - 15 msgs
Ewan Birney
birney@ebi.ac.uk
Tue, 30 Jan 2001 15:08:35 +0000 (GMT)
On Tue, 30 Jan 2001, Yuandan Zhang wrote:
> Hi,
> I am new to bioperl, very patinate in it. Is there any tutorial materials
> available or any collection of example scripts for beginners to make a start?
A tutorial will be availble in the 0.7 release (due to be branched soon).
>
> Yuandan
>
> At 04:17 AM 1/30/01 -0500, you wrote:
> >Send Bioperl-l mailing list submissions to
> > bioperl-l@bioperl.org
> >
> >To subscribe or unsubscribe via the World Wide Web, visit
> > http://bioperl.org/mailman/listinfo/bioperl-l
> >or, via email, send a message with subject or body 'help' to
> > bioperl-l-request@bioperl.org
> >
> >You can reach the person managing the list at
> > bioperl-l-admin@bioperl.org
> >
> >When replying, please edit your Subject line so it is more specific
> >than "Re: Contents of Bioperl-l digest..."
> >
> >
> >Today's Topics:
> >
> > 1. Genscan exon frame computation (Hilmar Lapp)
> > 2. LiveSeq back working (Joseph Insana)
> > 3. SeqFeature::Generic broken? no Location::Simple.pm (Mark Wilkinson)
> > 4. Re: SeqFeature::Generic broken? no Location::Simple.pm (Jason Stajich)
> > 5. Re: LiveSeq back working (Jason Stajich)
> > 6. Re: SeqFeature::Generic broken? no Location::Simple.pm (Ewan Birney)
> > 7. Bio Framework and XML (Iain Darroch)
> > 8. Bio::SeqFeature::Generic add_sub_SeqFeature (Jason Stajich)
> > 9. Re: Bio::SeqFeature::Generic add_sub_SeqFeature (Hilmar Lapp)
> > 10. Re: Bio::SeqFeature::Generic add_sub_SeqFeature (Jason Stajich)
> > 11. Re: RetrictionEnzyme.pm: a proposal (Hilmar Lapp)
> > 12. Re: missing use statements (Hilmar Lapp)
> > 13. Root::Object in bioxml.pm (Hilmar Lapp)
> > 14. Re: [Bioperl-guts-l] Notification: incoming/888 (Hilmar Lapp)
> > 15. Re: Bio::SeqFeature::Generic add_sub_SeqFeature (Ewan Birney)
> >
> >--__--__--
> >
> >Message: 1
> >Date: Mon, 29 Jan 2001 09:24:03 -0800
> >From: Hilmar Lapp <hlapp@gmx.net>
> >Organization: Nereis 4
> >To: Bioperl <bioperl-l@bioperl.org>
> >Subject: [Bioperl-l] Genscan exon frame computation
> >
> >A revisit of this is on the task list. I had a discussion a while
> >ago with Mark Dalphin, because he claimed that he managed to
> >figured out the exon frame based on start coordinate and frame
> >value.
> >
> >I still don't fully understand his code sample, as he was also
> >using his own definition of frame. Still, the discussion let me
> >see how one can figure out the frame. I've enclosed the relevant
> >code section of my implementation below. Whoever feels in the
> >position please review and double-check.
> >
> >This will add a frame attribute to each individual exon, which
> >makes it possible to deliberately shuffle exons from one
> >prediction (for those who aren't aware: Genscan with default
> >parameters outputs only exons in the 'optimal path'; there may be
> >other exons which also achieve very good scores and the output of
> >which can be triggered by -subopt).
> >
> >Things still to do in this respect comprise of a rigorous test
> >(take all exons of each prediction, translate them individually in
> >the frame they've been assigned, and check that there are no
> >intervening stops) and an adaptation of cds() in GeneStructure.pm
> >(when concatenating exons, make sure that the frame of one and
> >frame/phase of the previous match, and if not, fill with Ns).
> >
> >If anyone volunteers to add the test to Genpred.t I'd be really
> >glad. This does not involve module design, just plain application
> >coding, and anyone literate in Perl/Bioperl should be able to jump
> >in here.
> >
> >Comments welcome, esp. regarding the cds() comment I made above.
> >
> > Hilmar
> >--
> >-----------------------------------------------------------------
> >Hilmar Lapp email: hlapp@gmx.net
> >GNF, San Diego, Ca. 92122 phone: +1 858 812 1757
> >-----------------------------------------------------------------
> >
> ># Figure out the frame of this exon. This is NOT the frame
> ># given by Genscan, which is the absolute frame of the base
> ># starting the first predicted complete codon. By comparing
> ># to the absolute frame of the first base we can compute the
> ># offset of the first complete codon to the first base of the
> ># exon, which determines the frame of the exon.
> >my $cod_offset;
> >if($predobj->strand() == 1) {
> > $cod_offset = $flds[6] - (($predobj->start()-1) % 3);
> > # Possible values are -2, -1, 0, 1, 2. -1 and -2 correspond
> > # to offsets 2 and 1, resp. Offset 3 is the same as 0.
> > $cod_offset += 3 if($cod_offset < 1);
> >} else {
> > # On the reverse strand the Genscan frame also refers to
> > # the first base of the first complete codon, but viewed
> > # from forward, which is the third base viewed from
> > # reverse.
> > # Note that end() is in fact start() here because we always
> > # annotate in forward direction (otherwise we wouldn't need
> > # strand()).
> > $cod_offset = $flds[6] - (($predobj->end()-3) % 3);
> > # Possible values are -2, -1, 0, 1, 2. Due to the reverse
> > # situation, {2,-1} and {1,-2} correspond to offsets
> > # 1 and 2, resp. Offset 3 is the same as 0.
> > $cod_offset -= 3 if($cod_offset >= 0);
> > $cod_offset = -$cod_offset;
> >}
> ># Offsets 2 and 1 correspond to frame 1 and 2 (frame of exon
> ># is the frame of the first base relative to the exon, or the
> ># number of bases the first codon is missing).
> >$predobj->frame(3 - $cod_offset);
> >
> >--__--__--
> >
> >Message: 2
> >Date: Mon, 29 Jan 2001 17:48:19 +0000 (GMT)
> >From: Joseph Insana <insana@ebi.ac.uk>
> >Reply-To: insana@ebi.ac.uk
> >To: bioperl-l@bioperl.org
> >Subject: [Bioperl-l] LiveSeq back working
> >
> >LiveSeq is back working now.
> >The BioPerl loader was not working anymore because of the SplitLocation
> >change. It was using the subfeature method.
> >
> >Joseph Insana
> >
> >
> >--__--__--
> >
> >Message: 3
> >Date: Mon, 29 Jan 2001 11:38:24 -0600
> >From: Mark Wilkinson <mwilkinson@gene.pbi.nrc.ca>
> >Organization: PBI-NRC
> >To: bioperl-l@bioperl.org
> >Subject: [Bioperl-l] SeqFeature::Generic broken? no Location::Simple.pm
> >
> >Dear Group,
> >
> >I just cvs-updated and noticed that SeqFeature::Generic does not appear
> >to be functional anymore. It is calling on Bio/Location/Simple.pm
> >(line 122), which apparently does not exist. Is it just my installation
> >which is wonky, or is this a genuine bug?
> >
> >any advice appreciated.
> >
> >cheers all!
> >
> >M
> >
> >
> >--
> >---
> >Dr. Mark Wilkinson
> >Bioinformatics Group
> >National Research Council of Canada
> >Plant Biotechnology Institute
> >110 Gymnasium Place
> >Saskatoon, SK
> >Canada
> >
> >
> >
> >
> >--__--__--
> >
> >Message: 4
> >Date: Mon, 29 Jan 2001 13:05:34 -0500 (EST)
> >From: Jason Stajich <jason@chg.mc.duke.edu>
> >To: Mark Wilkinson <mwilkinson@gene.pbi.nrc.ca>
> >cc: bioperl-l@bioperl.org
> >Subject: Re: [Bioperl-l] SeqFeature::Generic broken? no Location::Simple.pm
> >
> >you need to do
> >% cvs update -d
> >to get newly created directories.
> >
> >On Mon, 29 Jan 2001, Mark Wilkinson wrote:
> >
> > > Dear Group,
> > >
> > > I just cvs-updated and noticed that SeqFeature::Generic does not appear
> > > to be functional anymore. It is calling on Bio/Location/Simple.pm
> > > (line 122), which apparently does not exist. Is it just my installation
> > > which is wonky, or is this a genuine bug?
> > >
> > > any advice appreciated.
> > >
> > > cheers all!
> > >
> > > M
> > >
> > >
> > > --
> > > ---
> > > Dr. Mark Wilkinson
> > > Bioinformatics Group
> > > National Research Council of Canada
> > > Plant Biotechnology Institute
> > > 110 Gymnasium Place
> > > Saskatoon, SK
> > > Canada
> > >
> > >
> > >
> > > _______________________________________________
> > > Bioperl-l mailing list
> > > Bioperl-l@bioperl.org
> > > http://bioperl.org/mailman/listinfo/bioperl-l
> > >
> >
> >Jason Stajich
> >jason@chg.mc.duke.edu
> >Center for Human Genetics
> >Duke University Medical Center
> >http://www.chg.duke.edu/
> >
> >
> >
> >--__--__--
> >
> >Message: 5
> >Date: Mon, 29 Jan 2001 13:05:59 -0500 (EST)
> >From: Jason Stajich <jason@chg.mc.duke.edu>
> >To: Joseph Insana <insana@ebi.ac.uk>
> >cc: bioperl-l@bioperl.org
> >Subject: Re: [Bioperl-l] LiveSeq back working
> >
> >Thanks for fixing this, I wasn't sure where to go to look.
> >
> >On Mon, 29 Jan 2001, Joseph Insana wrote:
> >
> > > LiveSeq is back working now.
> > > The BioPerl loader was not working anymore because of the SplitLocation
> > > change. It was using the subfeature method.
> > >
> > > Joseph Insana
> > >
> > > _______________________________________________
> > > Bioperl-l mailing list
> > > Bioperl-l@bioperl.org
> > > http://bioperl.org/mailman/listinfo/bioperl-l
> > >
> >
> >Jason Stajich
> >jason@chg.mc.duke.edu
> >Center for Human Genetics
> >Duke University Medical Center
> >http://www.chg.duke.edu/
> >
> >
> >
> >--__--__--
> >
> >Message: 6
> >Date: Mon, 29 Jan 2001 18:14:14 +0000 (GMT)
> >From: Ewan Birney <birney@ebi.ac.uk>
> >To: Mark Wilkinson <mwilkinson@gene.pbi.nrc.ca>
> >cc: bioperl-l@bioperl.org
> >Subject: Re: [Bioperl-l] SeqFeature::Generic broken? no Location::Simple.pm
> >
> >On Mon, 29 Jan 2001, Mark Wilkinson wrote:
> >
> > > Dear Group,
> > >
> > > I just cvs-updated and noticed that SeqFeature::Generic does not appear
> > > to be functional anymore. It is calling on Bio/Location/Simple.pm
> > > (line 122), which apparently does not exist. Is it just my installation
> > > which is wonky, or is this a genuine bug?
> >
> >
> >cvs update -d
> >
> >
> > >
> > > any advice appreciated.
> > >
> > > cheers all!
> > >
> > > M
> > >
> > >
> > > --
> > > ---
> > > Dr. Mark Wilkinson
> > > Bioinformatics Group
> > > National Research Council of Canada
> > > Plant Biotechnology Institute
> > > 110 Gymnasium Place
> > > Saskatoon, SK
> > > Canada
> > >
> > >
> > >
> > > _______________________________________________
> > > Bioperl-l mailing list
> > > Bioperl-l@bioperl.org
> > > http://bioperl.org/mailman/listinfo/bioperl-l
> > >
> >
> >-----------------------------------------------------------------
> >Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420
> ><birney@ebi.ac.uk>.
> >-----------------------------------------------------------------
> >
> >
> >--__--__--
> >
> >Message: 7
> >Date: Mon, 29 Jan 2001 18:40:07 +0000 (GMT)
> >From: Iain Darroch <darrochi@dcs.gla.ac.uk>
> >To: bioperl-l@bioperl.org
> >Subject: [Bioperl-l] Bio Framework and XML
> >
> >Hi All,
> >
> >I am currently looking at ways of integrating biological systems. I saw
> >mentioned in some of the documentation that a Bio-Object Framework was
> >proposed. Also that XML could be used in meta data for describing
> >bioinformatics objects.
> >
> >I was wondering what the current situation of both these were.
> >
> >Has anyone implemented parsers yet?
> >
> >Thanks in advance
> >
> >Iain
> >
> >
> >
> >
> >--__--__--
> >
> >Message: 8
> >Date: Mon, 29 Jan 2001 14:33:59 -0500 (EST)
> >From: Jason Stajich <jason@chg.mc.duke.edu>
> >To: Bioperl <bioperl-l@bioperl.org>
> >Subject: [Bioperl-l] Bio::SeqFeature::Generic add_sub_SeqFeature
> >
> >What is the feeling here, we have this old way of doing things which
> >included using the value 'EXPAND' to determine if we should expand the
> >start/end space for a feature when adding a sub_SeqFeature to a feature?
> >
> >I think this should likely be better modeled through a SplitLocationI
> >which is just a container of LocationObjects. So I propose to remove all
> >references to 'EXPAND' which means removing the method _expand_region and
> >updating add_sub_Feature to deal with adding the locations. Similarly the
> >flush_sub_SeqFeature should flush the locations, but I'm not sure about
> >what the start/end should be reset to...
> >
> >I also had to update FeaturePair to add the method location() which
> >delegates to feature1()->location() otherwise things won't work correctly.
> >start/end are defined by feature1 object so location should also reside
> >in feature1.
> >
> >Jason
> >
> >Jason Stajich
> >jason@chg.mc.duke.edu
> >Center for Human Genetics
> >Duke University Medical Center
> >http://www.chg.duke.edu/
> >
> >
> >
> >
> >--__--__--
> >
> >Message: 9
> >Date: Mon, 29 Jan 2001 13:09:40 -0800
> >From: Hilmar Lapp <lapp@gnf.org>
> >Organization: GNF
> >To: Jason Stajich <jason@chg.mc.duke.edu>
> >Cc: Bioperl <bioperl-l@bioperl.org>
> >Subject: Re: [Bioperl-l] Bio::SeqFeature::Generic add_sub_SeqFeature
> >
> >Jason Stajich wrote:
> > >
> > > What is the feeling here, we have this old way of doing things which
> > > included using the value 'EXPAND' to determine if we should expand the
> > > start/end space for a feature when adding a sub_SeqFeature to a feature?
> > >
> > > I think this should likely be better modeled through a SplitLocationI
> > > which is just a container of LocationObjects. So I propose to remove all
> > > references to 'EXPAND' which means removing the method _expand_region and
> > > updating add_sub_Feature to deal with adding the locations. Similarly
> >
> >Can't we keep a separate method for coping with region extension due
> >to a new subfeature, in whatever way the extension is done? As far as
> >I can remember I had a good reason to put it into its own method, I
> >needed it separately from add_sub_SeqFeature().
> >
> > Hilmar
> >--
> >-------------------------------------------------------------
> >Hilmar Lapp email: lapp@gnf.org
> >GNF, San Diego, Ca. 92121 phone: +1-858-812-1757
> >-------------------------------------------------------------
> >
> >--__--__--
> >
> >Message: 10
> >Date: Mon, 29 Jan 2001 16:26:21 -0500 (EST)
> >From: Jason Stajich <jason@chg.mc.duke.edu>
> >To: Hilmar Lapp <lapp@gnf.org>
> >cc: Bioperl <bioperl-l@bioperl.org>
> >Subject: Re: [Bioperl-l] Bio::SeqFeature::Generic add_sub_SeqFeature
> >
> >On Mon, 29 Jan 2001, Hilmar Lapp wrote:
> >
> > > Jason Stajich wrote:
> > > >
> > > > What is the feeling here, we have this old way of doing things which
> > > > included using the value 'EXPAND' to determine if we should expand the
> > > > start/end space for a feature when adding a sub_SeqFeature to a feature?
> > > >
> > > > I think this should likely be better modeled through a SplitLocationI
> > > > which is just a container of LocationObjects. So I propose to remove all
> > > > references to 'EXPAND' which means removing the method _expand_region and
> > > > updating add_sub_Feature to deal with adding the locations. Similarly
> > >
> > > Can't we keep a separate method for coping with region extension due
> > > to a new subfeature, in whatever way the extension is done? As far as
> > > I can remember I had a good reason to put it into its own method, I
> > > needed it separately from add_sub_SeqFeature().
> >
> >I guess it is more sane to let SeqFeature::Generic handle the common case
> >and the split location case will need to be handled elsewhere.
> >
> >In the special case of a feature with multiple locations that feature (or
> >object creating it) will take care of updating the location object to
> >point to a splitlocation object. For example, if we choose to have CDS be
> >represented as a SplitLocation with the exons being the parts in the
> >join(...) statement. This will have to be negotiated by the object
> >creating the Gene/CDS object.
> >
> >Okay so no changes to check in for Generic.
> >
> > >
> > > Hilmar
> > > --
> > > -------------------------------------------------------------
> > > Hilmar Lapp email: lapp@gnf.org
> > > GNF, San Diego, Ca. 92121 phone: +1-858-812-1757
> > > -------------------------------------------------------------
> > > _______________________________________________
> > > Bioperl-l mailing list
> > > Bioperl-l@bioperl.org
> > > http://bioperl.org/mailman/listinfo/bioperl-l
> > >
> >
> >Jason Stajich
> >jason@chg.mc.duke.edu
> >Center for Human Genetics
> >Duke University Medical Center
> >http://www.chg.duke.edu/
> >
> >
> >
> >--__--__--
> >
> >Message: 11
> >Date: Mon, 29 Jan 2001 13:57:13 -0800
> >From: Hilmar Lapp <lapp@gnf.org>
> >Organization: GNF
> >To: Paul-Christophe Varoutas <paul-christophe.varoutas@curie.fr>
> >Cc: bioperl-l@bioperl.org
> >Subject: Re: [Bioperl-l] RetrictionEnzyme.pm: a proposal
> >
> >Paul-Christophe Varoutas wrote:
> > >
> > > Tell me what you think about it:
> > > - First of all, is redesigning possible or are we obliged to maintain
> > > compatibility ? In the latter case I will just add functionality,
> > > maintaining the poor design of the module.
> > > - If redesigning is possible, please make comments/suggestions.
> > >
> >
> >First of all, keeping compatibility is a very good thing. Every user
> >of your software will appreciate it if he/she knows that this is taken
> >seriously.
> >
> >In general, my opinion is if there's no strong reason to break
> >compatibility, then don't break it. On the other hand, if there is a
> >good reason, then don't hesitate.
> >
> >This means, yes, redesigning is possible, but a nicer design by itself
> >is not a good reason to break compatibility. If the existing design is
> >sort of prohibitive for adding certain new functionality, this might
> >justify breaking compatibility. An example is the new location model,
> >but in fact Jason could manage to keep compatibility. I suggest that
> >you carefully examine whether you indeed can't redesign and at the
> >same time keep compatibility. Based on your proposal I don't see the
> >prohibitive point yet.
> >
> >As for the release, this issue is not on the task list, which means
> >that you are on your own. There's a deadline next week, and we don't
> >want to lose focus. If you finish the code and submit an accompanying
> >rigorous test in t/* on time, it can make it into the release though,
> >provided that there are no objections should you introduce
> >incompatibilities.
> >
> >As a last remark, a design that isn't prepared very well for an
> >extension one has in mind is not necessarily poor. It may just have
> >been perfect for its original scope. And: I really think that there is
> >no such thing as a "correct" design. Design may be bad or may be good,
> >generic or tailored, or whatever, it just depends on your viewpoint,
> >that is, on the particular problem you want to solve.
> >
> > Hilmar
> >--
> >-------------------------------------------------------------
> >Hilmar Lapp email: lapp@gnf.org
> >GNF, San Diego, Ca. 92121 phone: +1-858-812-1757
> >-------------------------------------------------------------
> >
> >--__--__--
> >
> >Message: 12
> >Date: Mon, 29 Jan 2001 23:02:45 -0800
> >From: Hilmar Lapp <hlapp@gmx.net>
> >Organization: Nereis 4
> >To: Bioperl <bioperl-l@bioperl.org>
> >Subject: Re: [Bioperl-l] missing use statements
> >
> >Paul-Christophe Varoutas wrote:
> > >
> > > so I just added one line at the beginning of the module to load Bio::Seq:
> > >
> > > use Bio::Seq;
> > >
> >
> >Thanks for pointing this out. The reason this became necessary all
> >of a sudden was probably that I removed the respective lines from
> >SeqIO.pm, because there was no obvious reason to keep them. Since
> >I still think that the 'use' statements are better in those files
> >where the modules are really used, I left it that way and added
> >the necessary use statements to all other SeqIO modules (which
> >probably would all have complained sooner or later).
> >
> > > and edited the @ISA array initialization line:
> > >
> > > @ISA = qw(Bio::SeqIO Bio::Seq);
> > >
> >
> >We don't want SeqIO modules to inherit from Bio::Seq.
> >
> > Hilmar
> >--
> >-----------------------------------------------------------------
> >Hilmar Lapp email: hlapp@gmx.net
> >GNF, San Diego, Ca. 92122 phone: +1 858 812 1757
> >-----------------------------------------------------------------
> >
> >--__--__--
> >
> >Message: 13
> >Date: Mon, 29 Jan 2001 23:04:21 -0800
> >From: Hilmar Lapp <hlapp@gmx.net>
> >Organization: Nereis 4
> >To: Bioperl <bioperl-l@bioperl.org>
> >CC: Jason Stajich <jason@chg.mc.duke.edu>
> >Subject: [Bioperl-l] Root::Object in bioxml.pm
> >
> >SeqIO::bioxml.pm still inherits from Root::Object. Is there a
> >particular reason that this one's an exception?
> >
> > Hilmar
> >--
> >-----------------------------------------------------------------
> >Hilmar Lapp email: hlapp@gmx.net
> >GNF, San Diego, Ca. 92122 phone: +1 858 812 1757
> >-----------------------------------------------------------------
> >
> >--__--__--
> >
> >Message: 14
> >Date: Mon, 29 Jan 2001 23:10:26 -0800
> >From: Hilmar Lapp <hlapp@gmx.net>
> >Organization: Nereis 4
> >To: Mark Wilkinson <mwilkinson@gene.pbi.nrc.ca>
> >CC: bioperl-l@bioperl.org
> >Subject: [Bioperl-l] Re: [Bioperl-guts-l] Notification: incoming/888
> >
> >bioperl-bugs@bioperl.org wrote:
> > >
> > > Generic Features created from a GFF string do not
> > > record Frame information, and when dumping the feature
> > > out as GFF it is invariably reported as frame = 0.
> > >
> > > The problem is multi-fold:
> > >
> > > (1) the _from_gff_string and _from_gff2_string
> > > subroutines in Generic.pm do not contain any code to handle the
> > > recording of Frame information in the feature object
> > >
> > > (2) GFF allows a "." as the frame (meaning info not available),
> > > while $Feature only allows 0,1, or 2. Thus it isn't clear how a
> > > GFF frame of "." should be recorded. My first thought was that a
> > > value of undef might return "." in a call to SeqFeatureI::gff_string,
> > > however...
> > >
> > > (3) ...it appears that even if there is no frame information
> > > available in a Feature object, it nevertheless passes the
> > > $Feature->can('frame') test in SeqFeatureI::gff_string
> > > and returns a (default??) value of 0 for the $Feature->frame call
> > > (though there *is* code there to assign the frame to
> > > "." if it fails the ->can test...)
> > >
> > > I am willing to fix this problem myself, but I would appreciate having
> > > a consensus from the group about which level of the problem needs to be
> > > fixed to keep everyone else's code happy.
> > >
> >
> >I think that frame information should be consistent between GFF
> >representation and object representation. '.' is equivalent to
> >undef, and otherwise the frame should be 0, 1, or 2, regardless of
> >object or GFF string.
> >
> > Hilmar
> >
> >--
> >-----------------------------------------------------------------
> >Hilmar Lapp email: hlapp@gmx.net
> >GNF, San Diego, Ca. 92122 phone: +1 858 812 1757
> >-----------------------------------------------------------------
> >
> >--__--__--
> >
> >Message: 15
> >Date: Tue, 30 Jan 2001 09:14:42 +0000 (GMT)
> >From: Ewan Birney <birney@ebi.ac.uk>
> >To: Jason Stajich <jason@chg.mc.duke.edu>
> >cc: Bioperl <bioperl-l@bioperl.org>
> >Subject: Re: [Bioperl-l] Bio::SeqFeature::Generic add_sub_SeqFeature
> >
> >On Mon, 29 Jan 2001, Jason Stajich wrote:
> >
> > > What is the feeling here, we have this old way of doing things which
> > > included using the value 'EXPAND' to determine if we should expand the
> > > start/end space for a feature when adding a sub_SeqFeature to a feature?
> > >
> > > I think this should likely be better modeled through a SplitLocationI
> > > which is just a container of LocationObjects. So I propose to remove all
> > > references to 'EXPAND' which means removing the method _expand_region and
> > > updating add_sub_Feature to deal with adding the locations. Similarly the
> > > flush_sub_SeqFeature should flush the locations, but I'm not sure about
> > > what the start/end should be reset to...
> >
> >I guess agree (I am wincing at every one of these decisions you know. It
> >just pains me to see us have to handle this object complexity in
> >essentially simple objects. Bugger-it! I know there is no way out here,
> >but .... it goes against the grain).
> >
> > >
> > > I also had to update FeaturePair to add the method location() which
> > > delegates to feature1()->location() otherwise things won't work correctly.
> > > start/end are defined by feature1 object so location should also reside
> > > in feature1.
> > >
> >
> >That is the consistent route here...
> >
> >
> > > Jason
> > >
> > > Jason Stajich
> > > jason@chg.mc.duke.edu
> > > Center for Human Genetics
> > > Duke University Medical Center
> > > http://www.chg.duke.edu/
> > >
> > >
> > >
> > > _______________________________________________
> > > Bioperl-l mailing list
> > > Bioperl-l@bioperl.org
> > > http://bioperl.org/mailman/listinfo/bioperl-l
> > >
> >
> >-----------------------------------------------------------------
> >Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420
> ><birney@ebi.ac.uk>.
> >-----------------------------------------------------------------
> >
> >
> >
> >--__--__--
> >
> >_______________________________________________
> >Bioperl-l mailing list
> >Bioperl-l@bioperl.org
> >http://bioperl.org/mailman/listinfo/bioperl-l
> >
> >
> >End of Bioperl-l Digest
>
>
>
>
> --
> Yuandan Zhang
>
>
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l@bioperl.org
> http://bioperl.org/mailman/listinfo/bioperl-l
>
-----------------------------------------------------------------
Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420
<birney@ebi.ac.uk>.
-----------------------------------------------------------------