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

[Chris Mungall]

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
>