New Bio::Seq and Bio::Seq::Parse (.025 BETA)

[Steven E. Brenner]

I'm leaving later today, so very quick comments...


> >   A few other nits from a _very_ cursory look-through
> > 
> > @SeqForm appears never to be created
> > 
> > I would change [@%]SeqForm to [@%]SeqFmt, or even [@%]seq_fmt (to be
> > consistent with the rest of the naming). 
> 
> I think then we should have seq_ffmt.
> Then again, doesn't SeqForm hint at the fact that these variables are 
> very special ?

Good Point; these are supposed to be constants, after all.  Then how about
SeqFmt? 


> > There's no 'valid' field to indicate whether or not the object is indeed
> > valid for any operation.  For example, if setseq is used to set an invalid
> > sequence.  
> 
> What if we don't allow this to happen ?
> If we keep the object valid all the time ?

That means that we have to 'croak' on any error rather than carp.  


> > Functions which can return an invalid result (such as parse_bad) should
> > return undef ratehr
> 
> You mean, rather than 0 ? I thought zero and the null string ("") 
> are interpreted as false, and returning 0 or "" seems the standard 
> convention, no ?

No.  undef, 0, and "" are all 'false' in Perl.  However undef is
qualitiatively different in that it returns 'false' to the defined()
function.  The others don't.  undef is "more false" than the others. 
Therefore failures are always supposed to be indicated as undef 
(except from syscall() and system() )