[Bioperl-l] Other object oddities

[Kevin Brown]

> > I don't mind that Bio::Seq uses seq to return a string. In fact I  
> > prefer
> > that. Just would be nice if other objects obeyed the same 
> convention.
> > Bio::SeqFeature::Generic returns an object for both entire_seq and  
> > seq,
> > but uses attach_seq to store the Bio::Seq object into the Feature.
> 
> I think most of these are legacy issues that (for the most 
> part) have  
> just been dealt with ('they just work'), and with the thought that  
> changing things breaks legacy code.  I agree with you, 
> though; it's a  
> good time to rethink how we're naming methods, work towards some  
> consistency, and possibly do this for the next significant 
> release.  I  
> don't want to fall into the trap that perl 5.x had fallen 
> into (and is  
> working towards digging out of), namely fear of breaking old code.
> 
> > Maybe SeqFeature could be adjusted so that ->seq returns 
> the sequence
> > string of the feature (just like Bio::Seq) and 
> ->feature_seq returns  
> > the
> > Bio::Seq object.
> 
> That would be a significant API change and would be 
> inconsistent with  
> seq() in other classes returning a Bio::Seq.  Not that it's any  
> different than some of the current behavior, but if we want 
> to correct  
> this it should be done in a *consistent*, well-defined way.

Changing it in either set of objects would be a break in the API. Either
it always returns an object or always returns a string. Right now
Bio::Seq/LocatableSeq/PrimarySeq/etc... and others of its ilk return
strings when calling ->seq() and also allow one to set the sequence with
that same method. Bio::SeqFeature::*, the Bio::DB objects, etc... only
allow one to get the seq object that way, but set it via a different
method.

> My thoughts:
> 
> To me, seq() should always return a Bio::PrimarySeqI (derived from  
> invocant PrimarySeqI class).  However, this is currently 
> inconsistent  
> as illustrated by your example.  Changing this would require a  
> deprecation cycle.
> 
> A new method, seqstr()/str()/rawseq(), could be guaranteed to 
> return a  
> raw sequence.  Similarly, bioseq(), could always return a  
> Bio::PrimarySeqI.

Those sound like possibilities. With one or another of the methods being
aliased to ->seq if you still want to keep the call around.