UnivAln 1.004 Beta

[Steven E. Brenner]

... gave the code an extremely quick look-thru.  Not many comments beyond
those previously noted.


> Note that if you accept a reference to a hash as the parameter,
> the key makes it possible to support a lot of possiblities in parallel,
> like ``{i=>'...'}'' for the final solution (whatever it is), or even
> ``{descs=>'...'}'' if you wanna support retrieval of sequences for which
> the description matches a certain pattern. For ids which have no whitespace,
> space-delimited strings look optimal. 

I tend to think that comma-separated is probably better.  A reference to
an array of strings is probably even better still, as that's presumably
what you use inside the routines that deal with these things.

The numbering in the code still seems pretty poorly documented/determined.

I agree that a hash permits many options.  But that potentially
just indicates lack of clear thinking and good design.  A tenet of OO
design is that you shouldn't have redundant interfaces; they raise the
learning curve (because there are more options to learn) and make the code
less efficient and more error-prone.


I note that you're still using %FormUnivAln and %TypeUnivAln rather than
the arrays @UnivAlnType and @UnivAlnForm.  These should be arrays, not
hashes.