[Bioperl-l] Moose [was Re: Other object oddities]
cjfields at illinois.edu
Wed May 6 18:41:48 EDT 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.
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:
>> 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.
>>> 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
>>> Bioperl-l mailing list
>>> Bioperl-l at lists.open-bio.org
>> Bioperl-l mailing list
>> Bioperl-l at lists.open-bio.org
> Bioperl-l mailing list
> Bioperl-l at lists.open-bio.org
More information about the Bioperl-l