[Bioperl-l] Moose [was Re: Other object oddities]

Wed May 6 22:41:48 UTC 2009

As a final bit: if we go the Moose route, we should be very careful  
about which MooseX modules we want.  I don't think we want to expand  
the dependency tree.  For instance, I am attempting to install one  
possible module (MooseX::Declare) and the dependency tree was  
ginormous and included modules only needed for installation.

chris

On May 6, 2009, at 12:56 PM, Mark A. Jensen wrote:

> Great discussion-- I have redacted the moose portions to http://www.bioperl.org/wiki/Talk:BioMoose 
>  and encourage all interested folks to log comments there as well.  
> cheers Mark
> ----- Original Message ----- From: "Chris Mungall" <cjm at berkeleybop.org 
> >
> To: "Chris Fields" <cjfields at illinois.edu>
> Cc: "BioPerl List" <Bioperl-l at lists.open-bio.org>; "Mark A. Jensen" <maj at fortinbras.us 
> >; "Kevin Brown" <Kevin.M.Brown at asu.edu>
> Sent: Tuesday, May 05, 2009 2:28 PM
> Subject: [Bioperl-l] Moose [was Re: Other object oddities]
>
>
>>
>> On May 5, 2009, at 7:31 AM, Chris Fields wrote:
>>
>>> On May 5, 2009, at 7:31 AM, Hilmar Lapp wrote:
>>>
>>>>
>>>> On May 4, 2009, at 3:01 PM, Mark A. Jensen wrote:
>>>>
>>>>> Maybe this should be an element of
>>>>> the "Align refactor" that perhaps should be an overall
>>>>> "Seq refactor".
>>>>
>>>> Possibly. Most importantly, it'd be great if someone would   
>>>> volunteer to summarize what's been said here so it won't get lost.
>>>
>>> Looks like mark's done it.
>>>
>>>>> Are you saying that the trunk is fair game for api additions
>>>>> for this issue?
>>>>
>>>> There's been talk some (a long, actually) time ago about BioPerl   
>>>> 2.0 that would start on a clean slate and not be bothered by   
>>>> backwards compatibility demands. That effort never really took  
>>>> off,  but maybe this is also a good time to ask the question  
>>>> again  whether it's better to introduce the API changes we desire  
>>>> in add/ deprecate/remove cycles, or in a more radical fashion  
>>>> starting on a  clean slate.
>>>
>>> That's what I'm thinking.
>>>
>>>> The obvious advantage of the former is that we get API  
>>>> improvements  sooner, but making them is possibly more dreadful,  
>>>> discouraging, or  not even doable due to compatibility  
>>>> constraints. The disadvantage  of the latter is that it really  
>>>> needs a committed crew of people to  see it through or otherwise  
>>>> all the nice changes die in some grand  but half-finished 2.0  
>>>> construction site. I think Chris also had  plans to branch off a  
>>>> Perl6 version of BioPerl - maybe those could  be the same efforts?
>>>
>>> I have been toying around with perl6 for a bit now (Rakudo on  
>>> Parrot implementation).  It's possible an alpha for perl6 will be  
>>> available  by christmas this year; Rakudo is now passing over  
>>> 11000 spec tests.
>>>
>>> Just to note, Perl6 is another beast altogether from Perl5.  Yes,   
>>> there is supposed to be a backwards compatibility mode, but no  
>>> one  has implemented that yet, and it likely won't be implemented  
>>> in the  near future.  Based on that I'm not sure we could really  
>>> call a  bioperl in perl6 bioperl 2.0, more like bioperl6 1.0, as  
>>> it would be  a complete refactor.
>>>
>>> As for perl5, it has a nice OO set of modules (Moose) that could  
>>> be  used for refactoring.  It implements roles and a few other  
>>> perl6-ish  bits (along with MooseX modules).  perl 5.10 also has a  
>>> few things  backported from p6, say(), given/when, state vars,  
>>> etc.  We could  require Modern::Perl (perl5.10 with strict/ 
>>> warnings pragmas on) and  Moose.  I have played around with both  
>>> and find them quite nice, so  I suggest if we were to start a 2.0  
>>> effort it should include Moose,  and we should push most of the  
>>> interfaces into roles.
>>
>> We're playing around with a rewrite of go-perl using Moose:
>> http://geneontology.svn.sourceforge.net/viewvc/geneontology/go-moose/OBO/
>>
>> This is early enough that parts could be scrapped or rewritten.   
>> Compatibility with bioperl is important.
>>
>> Speed was an initial concern but apparently there are some moose   
>> tricks to speed things up
>>
>> DBIx::Class compatibility is also important. Not sure if there is   
>> specific support for this yet
>>
>>
>>>
>>> Anyway, I grabbed the git repos for bioperl6 and biomoose (bioperl  
>>> implemented in Moose) on github.  We can set up something there   
>>> using those namespaces if needed.
>>>
>>>> I'm not trying to advocate one over the other here; rather, I'd   
>>>> like to help push on that front that is best able to capture the   
>>>> energy of volunteers, as that's what it takes in the end.
>>>>
>>>> -hilmar
>>>
>>> Depends on where everyone wants to place their efforts.  May be  
>>> less  work to port the most important core classes over to Moose,  
>>> and a  simple test implementation will give us an idea on what  
>>> works Role- wise and what doesn't.  From there we could work on p6  
>>> variants;  that would have to be a separate project altogether.   
>>> We could also  include a few other MooseX modules if it makes life  
>>> easier.
>>>
>>> chris
>>> _______________________________________________
>>> 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