Naming the modules; Mailing lists

[Steven E. Brenner]

> > I think we're talking at cross-purposes.  My question is about defining
> > the data inside the UnivAln object. What do we allow as data types for
> > names and other parameters passed in?  If it is anything (scalars or
> > references), then we have problems of copying.  If it is free-text, then
> > we have the problem that things we may define in the future may clash with
> > user-named items.
> 
> Can this be postponed if we mention in the POD that copy() 
> currently copies everything in the object, but that this may be
> subject to change ?

No, because:

 1) you don't know what to copy if it is a reference
 2) the text below doesn't restrict valid items in names.  Someone
    might put a referene in 'loc' which would break our code (if we
    later decide that these have to be text).  Similarly, somoene might
    chose text which we want to reserve for ourselves.


> Currently I just write, in the POD for new(),
> >>>>>
>             $names: A reference to a hash which stores {loc,name} pairs of 
>                     other database locations and corresponding names where 
>                     the alignment is located. Also, $names->{'seqs'}[$i]{'id'}
>                     and $names->{'seqs'}[$i]{'desc'} may hold the ids and 
>                     descriptions of the sequence number $i. They are currently
>                     just set if Fasta format is read, or if Bio::Seq objects
>                     are passed to the constructor, and they're included if
>                     Fasta format is written. More support is planned.
> <<<<<
>     


To keep this whole discussion from lingering forever, I suggest the
following:



==========
  Currently, loc and name must both be set as text, and must consist
entirely of a string matching the regexp /^[A-Za-z]\w*$/.  That is, they
must be a single "word" of at least one character, without a leading
underscore.

  This restriction is not enforced, but code which deviates is subject to
break in future releases.  Note also that the object may place any other
sort of items in the name string, so users of this hash should not rely on
accessing entries conforming the requirements above.  
==========

Basically, this allows us to put in references and _internal text tags and
values, without worrying about clashes.