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

Fri May 8 18:30:19 UTC 2009

On Wed, 06 May 2009, Chris Fields wrote:

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

Since we are on the topic of Moose dependencies,  here is a nice article
about it.
http://chris.prather.org/perl/moose-dependencies-a-lurid-tale/

-siddhartha

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