Naming the modules; Mailing lists

[Steven E. Brenner]

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

Well, the interface of specifying alphabets needs to be dealt with before
any public release.  The internals can stay more-or-less as-is.  But the
public beta absolutely needs to have the interface for these features
defined. 

Why don't you just copy what Chris does in Bio::Seq for now. 



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

Yes, this can definitely wait


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

Um, so long as _all_ code dealing iwth parsing is hidden except some very
general item "read from file without specifying the file type," then I
guess it can go out now.  But since it looks like the parsing for Bio::Seq
is going to be revamped very soon, it might make sense for Bio::UnivAln to
follow suit.




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

Again, interface issues can NOT be put off for non-beta releases.  This is
not so much an issue of changing code so much as just making a decision
(which will affect code dependencies later).  We should make the decision
before the beta release.



> > > 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'' ?)

If you use mixed case, then you don't know whether to type FastA or Fasta;
you also don't know if it is Msf or MSF.  If it is all lowercase, then
you're always sure!