thoughts/questions on Seq.pm and Parse.pm

[Steven E. Brenner]

Very quick notes...


> I just note that there's FileHandle::new_tmpfile() and the Camel
> seems to prefer this (p.485). 

But filehandle has now been depricated in favor of IO.  I don't much care
how the name is generated.


> > o Non-fatal use of Parse.pm if ReadSeq does not exist or not configured
> > I wrapped some code around an eval{} statement in Seq.pm that tries to
> > politely figure out if Parse.pm is available -- it checks for the presense
> > of an exported "OK" variable in Parse.pm. Is this the right approach?
> 
> I'd check for $PARSE::VERSION > release_number_which_you_need. 
> Maybe there's something better though.

This will work if Parse.pm installation is conditional on 
ReadSeq being present.  Probably that would be a good thing.



> > o Proposed validity markers
> >   - A marker that would be set to 'false' whenever Seq.pm makes a call to carp()
> >   - A marker to specify valid/invalid biosequence object
> > Are these permutations of the same idea or two different things? I'm also
> 
> They are both ways of defining what ``valid'' is. ..
> For me a valid object conforms to some requirements, like (for UnivAln), 
> that $self{type} is correct (especially that it reflects the fact that the 
> alignment is just a sequence bag, i.e.  the rows are of different length), 
> $self{id} has no whitespace, $self{desc} conforms to $self{descffmt}, 
> $self{row_ids}, etc, have the correct size.
> This is something I don't have time for right now, but it's needed eventually.

You don't want to have to check all those various things every time you do
an operation.  It would be much similar to have a $valid flag which is set
or cleared after every operation which changes internal variables which
could affect validity.