[Bioperl-l] Moose [was Re: Other object oddities]
Mark A. Jensen
maj at fortinbras.us
Wed May 6 13:56:03 EDT 2009
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 easier.
>> 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