Tue, 18 Feb 1997 12:57:25 +0000 (GMT)
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!) )
> 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
> 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,
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''
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 firstname.lastname@example.org
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
and Seq.pm, or better, link to the Bielefeld page ?
> Best Regards,
> Steve A. Chervitz E-MAIL: email@example.com
> 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
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.