[Bioperl-l] Other object oddities

[Chris Fields]

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.

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