[Bioperl-l] Re: code reuse with moose

[Siddhartha Basu]

On Tue, 18 Aug 2009, Chris Fields wrote:

>
> 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).

Thanks for clarifying that.

>
> > 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.

That's seemed to be a saner approach. Will play around with the builder
approach and get the tests passing at least.

thanks, 
-siddhartha


>
> chris