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

Sat May 9 15:26:42 UTC 2009

Decent article, but it is slightly misleading.  These are dependencies  
for Moose itself, which I don't have a problem with (off the subject,  
but I personally would like to add in a requirement for Modern::Perl!).

What I am worried about are lots of additional dependencies introduced  
using some of the 'syntactic sugar' in various MooseX modules.  For  
instance, MooseX::Declare, and MooseX::Method::Signatures (two popular  
ones):

http://deps.cpantesters.org/?module=MooseX%3A%3ADeclare&perl=any+version&os=any+OS
http://deps.cpantesters.org/?module=MooseX%3A%3AMethod%3A%3ASignatures&perl=any+version&os=any+OS

chris

On May 8, 2009, at 8:33 PM, Mark A. Jensen wrote:

> thanks Siddhartha- very informative [but he misquotes Eliot in his  
> header!]
> cheers MAJ
> ----- Original Message ----- From: "Siddhartha Basu" <sidd.basu at gmail.com 
> >
> To: <bioperl-l at lists.open-bio.org>
> Sent: Friday, May 08, 2009 2:30 PM
> Subject: [Bioperl-l] Re: Moose [was Re:Other object oddities]
>
>
>> 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
>> _______________________________________________
>> 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