Bioperl: Module collections...

[Steve A. Chervitz]

On Sat, 1 Aug 1998, Ewan Birney wrote:
> 
> On Fri, 31 Jul 1998, Steve A. Chervitz wrote:
> 
> > 
> > The name change should coincide with a functionality change, namely, 
> > adding a feature description mechanism. We'll have to hear from ChrisD 
> > and Ian about their progress along these lines.
> >  
> 
> In my opinion the feature description stuff *should not* be in the Seq
> object (the 'light-weight' sequence object) but in the heavyweight
> sequence object (what I call the 'Entry' object). My game plan has
> 
> 	PreSeq.pm -> Seq.pm (light weight object) from Chris
> 
> 	Entry.pm -> Ian's object adapted from his GSC objects that
> has features (and taxonomy and the kitchen sink...).
> 
> I think this is a much cleaner way of breaking up the problem than
> simply having a single heavy weight object. Entry.pm can have alot of
> 'magic' whereas Seq.pm should be lean and mean. (Of course Entry.pm
> should contain Seq.pm)...
> 
> 	From this point of view PreSeq can become Seq now, which is what I
> reckon. Other votes? (before Wednesday by any chance?)

Seems reasonable. 

I want to call your attention to some changes that I have made to PreSeq.pm 
which we might want to add to the version that becomes "Seq.pm". Some of 
my changes were designed for integration into my Bio::Root hierarchy or 
were related to autoloading and should *not* go into Seq.pm. However, I 
made a number of bug fixes and other functionality enhancements that should 
be considered. All of my changes are documented in the module itself 
located at:
http://genome-www.stanford.edu/perlOOP/bioperl/lib/Bio/PreSeq.pm


> > > b) Stevec's Blast module 
> > > 
> > > 	This use's Steves Bio::Root::Global (at least) and ??
> > > Bio::Root::Object 
> > > 
> > > 	Steve - can we get rid of these things? (Do you want to?)
> > > 
> > 
> > Well, my modules rely on these so they are a necessary part of my Blast 
> > distribution as it currently stands. You could put my Bio::Root directory 
> > under CVS as well (it's bundled with my Blast distribution). Removing 
> > them from my design would take a fair bit of non-trivial de-engineering 
> > that I would hesitate to do (but would consider if people complained loud 
> > enough :). 
> 
> Consider one complaint lodged ;) - but I am certainly not obsessive about
> it. I don't think we can really try to coordinate everything through
> Bio::Root which means Bio::Root *really* is Bio::SteveC::Root ;) --->
> 
> Lets work with the entire Root and Object (Root and Branch?) of the
> Blast.pm and see if we can trim it later on (with your blessing ;)).
> 
> For the moment shall we put the entire Blast stuff into the repository
> as it stands, then you can do a checkout, merge and commit for the new
> stuff, or does it make more sense to wait and perhaps for you to attach
> the directories yourself once we have made the CVS system? Your choice...

I vote for adding it as it stands and modifying as necesary later.


> > > Stevec - do you want to write bioperl.pod and the README (you seem the
> > > natural person for it as leader etc...)?
> > 
> > I can come up with a draft. Do you have some ideas in mind for what these 
> > documents should say? 
> 
> I think bioperl.pod should be like the perl.pod in the distribution -
> 
> 	a) A header of links into the other Bio:: classes (split into
> two groups - Core distribution and contributed)
> 
> 	b) Introduction to bioperl like --->
> 
> 		bioperl uses perl (and here is where to get it?)
> 
> 		bioperl is not an executable it is an extension of perl
> 
> 		The main objects (and docs) with a breif description
> 		of how they fit together
> 
> 		The core group and other html resources.
> 
> 
> 	c) some light hearted jokes about doing the Camel genome in the
> 	future.	
> 

How about also including some guidelines for various things:

  * Module documentation
  * Creating and submitting a new module
  * Exception handling
  * Argument handling
  * Handling of constants 

Some of these things are stylistic issues and could be phrased as 
suggestions. Enforcing standards would be very non-Perl but having some 
shared conventions would make code sharing/reuse/maintenance easier. 

SteveC
sac@genome.stanford.edu
=========== Bioperl Project Mailing List Message Footer =======
Project URL: http://www.techfak.uni-bielefeld.de/bcd/Perl/Bio/
For info about how to (un)subscribe, where messages are archived, etc:
http://www.techfak.uni-bielefeld.de/bcd/Perl/Bio/vsns-bcd-perl.html
====================================================================