Naming the modules; Mailing lists

[Georg Fuellen]

Steve,
> 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).

done, in UnivAln 1.003 beta (see homepage)

> * 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

ok; will wait until Bio::Seq does this, and then follow up.

> 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.  

ok. but that's part of the first non-beta release I suppose.

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

Would it suffice to term the parse_XY methods internal, calling 
them _parse_XY ? The interface would then just be via of the constructor -
files can only be read by constructing a new object, until the parsing
system is all-set.
Ok ?

> 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

ok. but that's part of the first non-beta release I suppose.

> > 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 ***)  

Why lowercase ? I don't see any advantage; it's just that we'd spend
lotsa time changing code, docu, test programs, etc. 
(What's wrong w/ ``Fasta'', ``Raw'', ``Nexus'' ?)

> > 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!

Ok, will change this to _undef.

> 

best wishes,
georg