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

[Chris Fields]

On May 5, 2009, at 1:28 PM, Chris Mungall wrote:

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

I don't think it needs to be scrapped.  A stable Moose-based BioPerl  
is probably still a ways off from production use (I would like to test  
out a bit of interface->role conversion).

> 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


I'm not sure about DBIx::Class, but I know Moose sometimes doesn't  
play well with Error.pm and it's exported methods (I think there is a  
conflict).  I believe there have been some musings in the past over  
changing Bio::Root::Exceptions to use Exception::Class or similar, so  
maybe this'll be the push to do so.

Startup speed is an issue with Moose but as you noted there are ways  
to optimize things.  And, truthfully, if we can get around the  
interface issues using roles it might actually help a bit.

chris