[Bioperl-l] Other object oddities

[Mark A. Jensen]

[I hear you re: $job]
Def. thanks for chiming- Maybe this should be an element of
the "Align refactor" that perhaps should be an overall
"Seq refactor".

Are you saying that the trunk is fair game for api additions
for this issue?
cheers
----- Original Message ----- 
From: "Chris Fields" <cjfields at illinois.edu>
To: "Mark A. Jensen" <maj at fortinbras.us>
Cc: "BioPerl List" <Bioperl-l at lists.open-bio.org>; "Kevin Brown" 
<Kevin.M.Brown at asu.edu>
Sent: Monday, May 04, 2009 2:20 PM
Subject: Re: [Bioperl-l] Other object oddities


> 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
>
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
> http://lists.open-bio.org/mailman/listinfo/bioperl-l
>
>