[Bioperl-l] return type of $feature->seq() (comments on acommit [bioperl/bioperl-live fcd90e0])

[Mark A. Jensen]

I +1 Hilmar, but note that already git is doing what it is designed to do: 
devolve development. My $0.02 is: that is how BioPerl will keep from becoming a 
dinosaur. I believe that we as a community, judging from the track of the last 
year or so, are committed to this evolution by devolution, and the move to git 
is part of that overall plan. The increase in IRC chatter, led by deafferet and 
rbuels, prefigured this and it was generally considered a Good Thing. So, I 
would propose that people (devs and users) make their views known (on list and 
elsewhere) about how best to communicate and have dev-oriented conversations: it 
may be that a listserv alone is not nimble enough. MAJ

----- Original Message ----- 
From: "Hilmar Lapp" <hlapp at gmx.net>
To: "BioPerl List" <bioperl-l at lists.open-bio.org>
Sent: Tuesday, May 25, 2010 5:10 PM
Subject: Re: [Bioperl-l] return type of $feature->seq() (comments on acommit 
[bioperl/bioperl-live fcd90e0])


> I'm a little concerned that this discussion is disconnected from the  list and 
> so misses a lot of possible input. Are we moving our  development discussion 
> to IRC or github commit comments?
>
> Regarding $feature->seq(), the API documentation expressly states that  the 
> return type is Bio::PrimarySeqI, as it does for $feature-
> >entire_seq().
>
> The original rationale for that was to avoid circular references.  Bio::SeqI 
> objects contain references to attached features, which in  turn contain a 
> reference to the seq object they are attached to.  A  Bio::SeqI object holds 
> the basic sequence properties (everything  except annotation and feature 
> objects) in a Bio::PrimarySeq delegate,  which is what a feature keeps a 
> reference to, not the containing  Bio::SeqI object.
>
> It's possible that S::U::weaken() can solve the circular reference  problem, 
> but this fact should be tested. I.e., attach a feature with a  SeqI-reference 
> to a SeqI, dispose the SeqI, and then test that the  feature has lost the 
> reference to the SeqI too.
>
> This still leaves the issue though that then you have a SeqFeatureI  object 
> with a dangling reference to a sequence object. If you have  those SeqFeatureI 
> objects stored in a feature store, this may wreak  havoc. I'd like to see 
> convincing arguments that it doesn't.
>
> Bottom line - just forking on git and committing a change isn't a  substitute 
> for bringing up an issue and possible solutions on the  list, and the vetting 
> of pull requests can fall upon only one or two  core developers. Two eyeballs 
> often spot a lot less than a hundred.
>
> -hilmar
>
> On May 25, 2010, at 2:02 PM, GitHub wrote:
>
>> Ah, but my link's old, forget it.  This one is better: 
>> http://book.git-scm.com/4_undoing_in_git_-_reset,_checkout_and_revert.html
>>
>> From: cjfields
>> View this commit online: 
>> http://github.com/bioperl/bioperl-live/commit/fcd90e0f2fa94b61ff8351157129678417c32991
>
> -- 
> ===========================================================
> : 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
>
>