[Bioperl-l] code reuse with moose

[Chris Fields]

On Aug 18, 2009, at 6:01 AM, Siddhartha Basu wrote:

> Putting it in the bioperl list,  makes more sense here,
>
> On Wed, 12 Aug 2009, Chris Fields wrote:
>
>> (BTW, this is re: the reimplementation of major chunks of BioPerl  
>> using
>> Moose, Biome: http://github.com/cjfields/biome/tree/)
>>
>> Locations should use a Role (specifically, Biome::Role::Range), so
>> start/end/strand should be attributes, not methods.  With  
>> attributes the
>> best way to do this is probably with a builder, and lazily (start
>> requires end, and vice versa).  Factor out the common code as Tomas
>> indicates.  BTW, the $self->throw() is akin to BioPerl's $self- 
>> >throw()
>> exception handling; it simply catches any exceptions and passes  
>> them to
>> the metaclass exception handling.
>>
>> I've been thinking about making the Range role abstract for this very
>> reason (or defining very basic attributes); something like:
>>
>> ----------------------------
>>
>> package Bio::Role::Range;
>>
>> requires qw(_build_start _build_end _build_strand);
>>
>> # also require other methods which need to be defined in  
>> implementation
>>
>> has 'start' => (
>>     isa      => 'Int',
>>     is       => 'rw',
>>     builder  => '_build_start',
>>     lazy     => 1
>> );
>>
>> # same for end, strand (except strand has a different isa via
>> MooseX::Types)
>> ....
>>
>> package Bio::Location::Foo;
>>
>> with 'Bio::Role::Range';
>>
>> sub _build_start {
>>   # for location-specific start
>> }
>>
>> sub _build_end {
>>   # for location-specific end
>> }
>>
>> sub _build_strand {
>>   # for location-specific strand
>> }
>>
>> sub _common_build_method {
>>   # factor out common code here, call from other builders
>> }
>>
>> ----------------------------
>
> This plan makes things much clearer. Currently the  
> BioMe::Role::Location has a 'requires' keyword and rest of the
> location modules consume that role to have its own implementation. At
> this point on BioMe::Location::Atomic has attribute based 'start' and
> 'end' implememtation. I got a bit confused because in current bioperl
> 'Bio::Location::Simple' inherits from 'Bio::Location::Atomic' and when
> i am trying to follow that path in BioMe it has to override that  
> method.
> So, my question is do all the location modules really needs to  
> inherits
> from each other. I am totally aware about the origianl design ideas  
> but
> it would be better to have a flatten hierarchy if possible.

Flattening with roles is always a good idea, yes.  I wouldn't worry as  
much about the way it was originally implemented as the general API  
(and ways in which we can simplify it).

> One more thing,  what about putting the 'start',  'end'  and the other
> common base attributes in BioMe::Role::Location instead of
> BioMe::Role::Range. I am not sure which would be correct from bioperl
> stand of view,  just throwing out an idea.

That's a possibility.  To me Locations are just Ranges with different  
behavior (hence the below comment...)

>> Also, I think the Coordinate-related stuff should be simplified  
>> down to a
>> trait or an attribute; they bring in way too much overhead in  
>> bioperl w/o
>> much added value.
>
> You mean instead of having 'builder' method,  having a specialized
> traits handling those. That sounds like even better.
>
> -siddhartha

Yes, that's essentially it.  Location behavior could be changed by  
having CoordinatePolicy as a trait.  Similarly, fuzziness for start/ 
end could also be thought of as a trait.  In essence, you could  
probably role most behavior into attribute traits (which, in Moose,  
are just roles that are composed into the attribute meta class,  
Moose::Meta::Attribute).  I had started up a Biome::Meta::Attribute  
class in case we were to go down this path, then we could start  
registering specific traits within that namespace.

Just to note, it might be easier to try the simplest approach first  
and get tests passing, then layer in traits to see how they act  
performance-wise.  My guess is they will speed things up, but you  
never know.  Locations will be a performance bottleneck as they are  
used in generic Features.

chris