Naming the modules; Mailing lists

[Steven E. Brenner]

Georg,

> I just sent the fax to you -re- clarification of
> some of your comments about Bio::Aln.



I got just 3 pages, and here are my comments -

Page 1.
*  If you don't want to build a separate module with PGPLOT compatibility
in this release, I would remove the PGPLOT code entirely from the first
release.  It isn't critical for the module's functioning, and it with
prevent most people from using the code (as they don't have PGPLOT).

* The "all parsing in one place" refers to the idea proposed earlier, in
my long email after going through the code -- that there should be a
separate set of parsing code

Page 9.  

* Alphabets.  See the notes in Bio::Seq.  My idea is that there should be
various alphabets, plus flags to indicate degrees of flexibility.  It
seems that the actual data is best stored as a string rather than a list. 
The gap, etc, should be dealt with in the evalation function depending
upon appropriate flags.  Hopefully, the code from Bio::Seq can be used in
Bio::UnivAln.  

* Parsing code.  I'm not sure this can wait -- changes in the mechanism
may cause changes in the interface


Page 29

* The problem with the copy routine is that types of the data being copied
(i.e., the names) has not been defined.  I think that we need to mkae up
our minds about what should be permitted.  It is probably better to be
extremely restrictive at first and add more flexibility later as it
becomes necessary



> You suggested to replace %TypeAln by @AlnType, and a similar
> change in Bio::Seq :
> Would it then be possible to have several acronyms for one format,
> like FASTA,Fasta,fasta -> Format No. 7 ?

Yes.  But format #7 would always have to map back to a single
name.  However, I woudl strongly argue that there should just be one name
for each format -- otherwise we lead to endless confusion.  Further, I
would propose that the names should be all lowercase.  (*** This requires
a change to both Bio::Seq and Bio::UnivAln ***)  

> Btw, should I clean up the numbering (I'm currently using
> the very old one from your Grid::Seq code)

If there is common parsing code, then it may be necessary for the numbers
in the different modules to agree.  At present, however, the
correspondance doesn't matter.   So long as the numbers are non-negative,
everything should be ok.


> Will wait for Chris Dagdigian to resolve the alphabet handling stuff..
> 
> I don't agree w/ using _undef instead of _nofile; ``_nofile'' is explicitly
> saying that no file should be read; _undef looks like a possible error.
 
Why does _undef look like an error?  Both "_undef" and "_nofile" mean
introducing a whole new type of syntax to the modules.   Adding just one
type of new syntax seems much better than adding two!