[Bioperl-l] Bio::FeatureHolderI

[Jason Stajich]

On Mon, 18 Nov 2002, Hilmar Lapp wrote:

> Yes, that's one way. An alternative is to define an interface an
> implementation of which must be passed in. Cleaner (and I think
> that's how BioJava does it), but maybe unnecessarily complicated in
> bioperl. I'm leaning towards your shortcut for simplicity reasons.
>
> If simple filtering by matching attribute values is to be
> implemented by the FeatureHolderI itself like you suggest, I'd vote
> for having those args match the parameter names you supply to new().
> I.e., for filtering by tag this would mean -primary and -source,
> depending on which attribute you want to filter (which BTW exposes
> another annoying inconsistency we have: parameter names should be
> the same as the method names [with a hyphen preprended]).
>
> Votes/comments/suggestions solicited ...

What about filtering on location?

>
> 	-hilmar
>
> On Monday, November 18, 2002, at 12:03 AM, Lincoln Stein wrote:
>
> > The Bio::Das and Bio::DB::GFF get_SeqFeatures methods both support
> > filters, so
> > I am happy if you formalize this.
> >
> > I suggest two ways to filter, to start with:
> >
> > 	(-tag => \@tag_list)
> >
> > Filter on the basis of a list of primary tags.  The returned
> > features are a
> > union or ORing the tags.
> >
> > 	(-filter => \&filter)
> >
> > Pass each feature to the filter subroutine.  Return features for
> > which the
> > subroutine returns true.
> >
> > Lincoln
> >
> > On Sunday 17 November 2002 06:55 am, Hilmar Lapp wrote:
> >> I'd suggest adding this alongside AnnotatableI. The benefit is not
> >> new functionality, but rather imposing a more rigorous and fostering
> >> a more consistent API structure on those classes that have features.
> >>
> >> I have the module ready to commit, and I'd adjust Bio::Seq and
> >> SeqFeature::Generic to implement this (clearly not very difficult).
> >> What do people thing? Core guys? This should be very similar to the
> >> biojava model, but I haven't checked that for a while.
> >>
> >> =head2 get_SeqFeatures
> >>
> >>   Title   : get_SeqFeatures
> >>   Usage   :
> >>   Function: Get the feature objects held by this feature holder.
> >>   Example :
> >>   Returns : an array of Bio::SeqFeatureI implementing objects
> >>   Args    : none
> >>
> >> At some day we may want to expand this method to allow for a feature
> >> filter to be passed in.
> >>
> >> =cut
> >>
> >> =head2 feature_count
> >>
> >>   Title   : feature_count
> >>   Usage   : $obj->feature_count()
> >>   Function: Return the number of SeqFeatures attached to a feature
> >> holder.
> >>
> >>             This is before flattening a possible sub-feature tree.
> >>
> >>             We provide a default implementation here that just counts
> >>             the number of objects returned by get_SeqFeatures().
> >>             Implementors may want to override this with a more
> >>             efficient implementation.
> >>
> >>   Returns : integer representing the number of SeqFeatures
> >>   Args    : None
> >>
> >> At some day we may want to expand this method to allow for a feature
> >> filter to be passed in.
> >>
> >> Our default implementation allows for any number of additional
> >> arguments and will pass them on get_SeqFeatures(). I.e., in order to
> >> support filter arguments, just support them in get_SeqFeatures().
> >>
> >> =cut
> >>
> >> =head2 get_all_SeqFeatures
> >>
> >>   Title   : get_all_SeqFeatures
> >>   Usage   :
> >>   Function: Get the flattened tree of feature objects held by this
> >>             feature holder. The difference to get_SeqFeatures is that
> >>             the entire tree of sub-features will be flattened out.
> >>
> >>             We provide a default implementation here, so implementors
> >>             don''t necessarily need to implement this method.
> >>
> >>   Example :
> >>   Returns : an array of Bio::SeqFeatureI implementing objects
> >>   Args    : none
> >>
> >> At some day we may want to expand this method to allow for a feature
> >> filter to be passed in.
> >>
> >> Our default implementation allows for any number of additional
> >> arguments and will pass them on to any invocation of
> >> get_SeqFeatures(), wherever a component of the tree implements
> >> FeatureHolderI. I.e., in order to support filter arguments, just
> >> support them in get_SeqFeatures().
> >>
> >> =cut
> >>
> --
> -------------------------------------------------------------
> Hilmar Lapp                            email: lapp at gnf.org
> GNF, San Diego, Ca. 92121              phone: +1-858-812-1757
> -------------------------------------------------------------
>
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l@bioperl.org
> http://bioperl.org/mailman/listinfo/bioperl-l
>

-- 
Jason Stajich
Duke University
jason at cgt.mc.duke.edu