This is a page for discussion of possible design directions for a Moose-based BioPerl core implementation.
A GitHub repository has also been reserved for this purpose.
What is Moose?
Moose is a post-modern object system for Perl (specifically, perl5). It is an extension of the p5 object system that implements several modern concepts in OOP, foremost among them Roles and MOP, and is designed to make OOP in perl easier.
For more information:
Module docs for Moose (including the cookbook and manual).
For Moose extensions:
And, of course, the Moose homepage.
What about all those freakin' dependencies? They are explained here.
Roles, Interfaces, Classes, or Composition?
Most interface classes or other utility-like classes (IO functionality, for instance) may be good candidates for a Role instead. in fact, we could convert all interfaces over to Roles fairly easily. This may cut down on inheritance-related issues within BioPerl.
Cases where a class or interface defines more of a has-a relationship. These could be retained as a simple Role (see above).
Types and type coercions
Moose has a rich data type system that allows for definition of custom types. They allow for clean input validation in a systematic, coherent way throughout all methods of a distribution. This helps to factor out all common type validation and error handling code on data input, making methods shorter, cleaner and more consistent.
Moreover, type coercions can be used to interconvert between different compatible types in an automatic way, increasing the DWIMness of the API. For instance, a method might act upon a Bio::Seq object. Defining proper type coercions, the method could automatically accept a sequence scalar, a Bio::SeqIO object, a filename scalar, a Bio::SimpleAlign object, etc; doing whatever it takes to get a Bio::Seq object from the input given.
The design elements may help elucidate what would work best in a BioPerl6 implementation.