[Bioperl-l] Other object oddities

[Chris Fields]

Sorry I haven't chimed in, but $job had killed me the last couple weeks!

Unfortunately the reason this hasn't been chased down before is the  
headache involved.  It requires significant API changes to a broadly  
used codebase (read: so devs are scared about breaking someone's old  
scripts), having to deal with deprecation cycles, not to mention the  
most critical aspect, which would be tuits.

Saying that, the reason I made a 1.6 branch is to maintain the  
snapshot of the code for API reasons.  There is no reason we can't add  
in more explicit methods to main trunk.  We can deprecate the use of  
more ambiguous methods down the road.

chris

On May 4, 2009, at 10:50 AM, Mark A. Jensen wrote:

> This is definitely a reasonable issue to chase down. How to do it  
> needs
> a little care. I personally see 'seq' and think 'object', and have  
> resorted to
> 'seqstr' in my own code to hold/access just strings. FWIW, my  
> preference would
> be to have any object that has a seq object as a property return  
> objects
> when a '..._seq' accessor is called. However, the seq objects  
> themselves
> generally contain the sequence string in their seq() property. We  
> wouldn't
> want to disrupt that, but would it be worth creating an alias getter/ 
> setter for
> the Seq classes seq() property called 'seqstr'? We could then count on
>
> $foo->bar_seq, an object
> $foo->bar_seq->seqstr, a string
> $foo->seqstr, a string (not nec same as above)
>
> cheers Mark
> ----- Original Message ----- From: "Kevin Brown" <Kevin.M.Brown at asu.edu 
> >
> Cc: "BioPerl List" <Bioperl-l at lists.open-bio.org>
> Sent: Monday, May 04, 2009 11:31 AM
> Subject: Re: [Bioperl-l] Other object oddities
>
>
>> 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.
>>
>> 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.
>>
>>> -----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
>>
>
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioperl-l