Bio::Seq (fwd)

[Georg Fuellen]

Forwarded message:
========================

Steve :

Just checked your great stuff, I'm very impressed ! Very exciting :)

(btw, how would you like to be addressed, given that I don't
want mixups between Steve(n) Brenner and you ? SteveC? Steve Ch.?
versus SteveB / SteveBr / Steve Br. (???, advice please!) )

> Georg,
...
> Regarding the Bio::Perl modules I've been working on, they are not quite 
> ready for prime time yet, so I have not officially presented them 
> anywhere. I overhauled them at the end of last year, but progress has 
> been slowed by other efforts. I've borrowed some ideas from the 
> Bio::Seq code and I have a sheme to integrate Bio::Seq and Bio::Aln with my 
> modules.
> 
> I added some links to your's and Steve Brenner's Bioperl pages at my 
> perlOOP site:  http://genome-www.stanford.edu/~sac/perlOOP/

Thanks, I'm now linking to your page as well.

> I will post some info on my own Bioperl efforts on this page. In 
> particular, I'll have a figure of by Bio::Perl object schema on this 
> page that I would like your opinion on, since it incoroprates Bio::Seq 
> and Bio::Aln.

I've copied in Chris Dagdigian and Steve Brenner, since they'll be
more involved into these issues than I will be (I fear that I won't have 
time to delve into genome/structure issues, but I promise to do my best
to modify Bio::Aln to suit your needs better.)

I would *very much* appreciate any and all comments on Bio::Aln,
same as Chris Dagdigian for Bio::Seq.

Regarding your Bio::Object schema, 
http://genome-www.stanford.edu/~sac/perlOOP/bioperl/bioObject_schema.gif

1) I like your object hierarchy in general, although I lack the knowledge
to comment on the genome/structure classes/hierarchy. The IS-A/HAS-A 
relationships make sense to me.
2) I've reproduced my reservations -re- Object, Err, etc, below,
for Chris+Steve Br's reference.
3) Is the %names hash in Bio::Aln sufficient for the moment to hold db, 
prog, etc ? Or would you like to see individual accessors ?
4) I'm interested in your results deriving Blast from Aln, and I'll do my
best -re- necessary modifications to Bio::Aln.
5) I'm unclear about the Sacch stuff, and the stuff below GeneSeq.
I think this doesn't matter, though.
6) It would be very exciting to see Perl as a standard tool for a lot
of bio applications ! Your efforts are a big encouragement for me !

Regarding the ``Programming Style Conventions for Bioperl Modules''
http://genome-www.stanford.edu/~sac/perlOOP/bioperl/style.html
I've followed the recommandations in the ``Module List'', especially
``Function and method names seem to work best as all lowercase. E.g.,
$obj->as_string().'' Anyway, now that people are testing the Aln & Seq 
code, it's (almost) too late to make changes like introducing 
upper-case for methods. Also, I've definitly become a fan of merging
accessor and modifyer into one function.

I've printed out your Molecule and Blast classes and will read thru them
in a few days; for which other texts would you recommand closer inspection ?

If possible, let's send most email to vsns-bcd-perl@lists.uni-bielefeld.de 
so that it's archived, and seen by everyone involved.
*May I bounce this email to vsns-bcd-perl ?*
You need to subscribe to the vsns-bcd-perl list (see homepage), because
bioperl@mole will be phrased out (Steve has moved to Japan).

Can you update
http://genome-www.stanford.edu/~sac/perlOOP/bioperl/lib-perl/Bio2/Aln.pm
and Seq.pm, or better, link to the Bielefeld page ?

best wishes,
georg

> Best Regards,
> 
> Steve
> ---------------------------------------------------------------------
> Steve A. Chervitz               E-MAIL: sac@genome.stanford.edu
> Department of Genetics             FAX: (415)723-7016
> Stanford University                TEL: (415)725-8956
> Stanford, CA 94305-5120           HTTP: www-genome.stanford.edu/~sac
> ----------------------------------------------------------------------
> 

-re- Object, Err, etc at
http://genome-www.stanford.edu/~sac/perlOOP/bioperl/bioObject_schema.gif
>>>>>>>>>
GF> > I must admit I'm a Perl newbie... Wouldn't all your stuff add
GF> > to the overhead that each object carries with it, and impair running
GF> > time performance ? Steve B. already noted that too much error checking
GF> > and robustness slows down the Bio::Seq code, I need to be careful there,
GF> > or start to design+code Bio::SeqLite...

> This is the ultimate tradeoff. One possiblity is to enable the
> script to select different levels of error checking and different types
> of base objects. You would run with little or no checking and a minimal
> base object when performing routine tasks on data you can trust but you
> would use maximum checking when dealing with new data or when running in
> a CGI context (ie., interacting with the real world!). Designing this
> kind of flexibility may take some thought.  For now, I'm content with
> slower code that gives results I can trust.

GF Right. It's also a problem if too many issues need to be thought about..
GF I spent hours trying to get the make / make test / make install
GF stuff running, to no avail. No time anymore to look into CPAN, even
GF though it's nice and needs to be looked into at some point.
GF I fear your ideas are great, but may add too much complexity
GF to an over-complicated world ?!

GF> > In general I'm wondering whether rank, and srcObj in particular,
GF> > is not something that should be done by a dedicated external object
GF> > (maybe even a relational/OO database maintenence system),
GF> > or at least another object that has the other objects as instance variables ?
>
> Yes. That would help make the base Object simpler but it adds some
> complexity in that the objects will need to interact with the manager
> object(s). It is kind of nice to have everything encapsulated in the 
> object but It may be worth experimenting with other ideas.
<<<<<<<<