Naming the modules; Mailing lists

[Georg Fuellen]

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

What if I don't mention any alphabet support in Bio::UnivAln ?

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

It will follow suit as soon as that's possible.

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

What's your suggestion about the issue, then ?
Copy everything in the object recursively, except X ? What is X ?

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

Good point. Will change this.

best wishes,
georg

> 
>