"Fiers, M.W.E.J." wrote:
> Hi
> <snip/>
> * A way of storing several set's of sub_seqfeature's, much like the current
> 'tags' system, but returning an array of seqfeatures. This is to make it
> easier to parse and separate subsets of sub_seqfeature's. The sub_seqfeature
> method could stay intact and just return all sets.
> Advantages to this structure would be that if somebody inherits from this
> object and stores seqfeature's of children of seqfeature's in this
> structure, it would still be parsable without the parsing having to know
> exactly what subset's are there.
BioJava uses FeatureFilter objects to pull out a sub-set of child features. This
has the added benefit that you can pull out any sub-set, not just those that the
data-publisher thought would be usefull. This ability to arbitrarily filter
features turns out to be a real time-saver. If you code it up right, it doesn't
affect object encapsulation, and the queries can be optimized into SQL, DAS or
whaterver other query languages (can anybody say 'compiler' / 'interpreter' ?).
We have well-known filters for locations, names, key/value pairs and a
collection of boolean operators (and, not, or etc.), but the user can always
supply their own routine.
Just my 2c. Feel free to ignore me - Perl is not Java.
Matthew
>> Mark Fiers
>> _______________________________________________
> Bioperl-l mailing list
>Bioperl-l@bioperl.org>http://bioperl.org/mailman/listinfo/bioperl-l