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

[Mark A. Jensen]

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