[Bioperl-l] Moose [was Re:Other object oddities]
Chris Fields
cjfields at illinois.edu
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
More information about the Bioperl-l
mailing list