[Bioperl-l] Other object oddities

[Chris Fields]

On May 4, 2009, at 10:31 AM, Kevin Brown wrote:

> 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.

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.

chris

>> -----Original Message-----
>> From: Hilmar Lapp [mailto:hlapp at gmx.net]
>> Sent: Sunday, May 03, 2009 11:37 AM
>> To: Kevin Brown
>> Cc: BioPerl List
>> Subject: Re: [Bioperl-l] Other object oddities
>>
>> I agree, $seq->seq() could possibly be better named. Maybe $seq-
>>> seqstr()?
>>
>> The thing is that having $seq->seq() return an object would be
>> meaningless - it would be $self.
>>
>> You can test what kind of object you have using ref() or isa():
>>
>> 	$seq = $obj->seq();
>> 	# we need the sequence string
>> 	$seq = $seq->seq() if ref($seq) &&
>> $seq->isa("Bio::PrimarySeqI");
>>
>> There has been a naming consistency review, but it's been a long  
>> time.
>>
>> -hilmar
>>
>>
>> On Apr 30, 2009, at 5:56 PM, Kevin Brown wrote:
>>
>>> So, I'm using quite a bit of bioperl code in my own stuff and have
>>> been
>>> seeing some oddities with the naming of methods. A good example
>>> would be
>>> in the Bio::Seq and Bio::SeqFeature::Generic. Both have a method
>>> called
>>> "seq" but in the latter case it returns an object (and expects an
>>> object
>>> when doing a Set) and in the former it returns a string and
>> expects a
>>> string when doing a Set.
>>>
>>> This makes for a bit of brain freeze on my part when the return from
>>> another object might be a Bio::Seq or
>> Bio::SeqFeature::Generic and now
>>> calling the ->seq returns different things.
>>>
>>> Guess I'm just curious if anyone has done an audit of the
>> methods of
>>> the
>>> various objects and their return types to see how
>> consistent they are
>>> across even a subsection of the codebase?
>>>
>>> _______________________________________________
>>> Bioperl-l mailing list
>>> Bioperl-l at lists.open-bio.org
>>> http://lists.open-bio.org/mailman/listinfo/bioperl-l
>>
>> -- 
>> ===========================================================
>> : Hilmar Lapp  -:-  Durham, NC  -:-  hlapp at gmx dot net :
>> ===========================================================
>>
>>
>>
>>
>
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioperl-l