[Bioperl-l] Bio::FeatureHolderI interface confusion
pedlefsen at systemsbiology.org
Wed Jun 18 18:45:31 EDT 2003
I will stick my neck out and propose that we a) fix FeatureHolderI to
have the right method names, b) separate out the add, remove
(mutability) methods into a separate interface (MutableFeatureHolderI?),
c) make SeqFeatureI inherit from FeatureHolderI d) make SeqI and Generic
both inherit from MutableFeatureHolderI.
I'll be working on folding my freaky-dev Collection consolidation back
into the main trunk starting on July 15th, carefully of course. This
will bring much joy and sorrow. Hopefully joy for y'all and sorrow only
for me, who has to do this without being targeted for assassination by
anybody who uses bioperl and liked it how it was thank-you-very-much. I
will be taking input as I go along but will have to balance getting it
done with satisfying everyone. If you are curious you may take a look
at that branch right now. I would be happy to separate out mutability
in the CollectionI interface as well, if we all like that idea. If
anyone is opposed on principle to consolidating all of the many
implementations of FeatureHolderI/CollectionI, speak now. I did my best
to make everything backwards compatible; all bioperl tests presently
pass on the freaky-dev-branch, so it *should* be relatively painless.
To divert attention by opening another can of worms: being forced to
make things backwards compatible is fun in its way... but wouldn't it be
even more fun to rewrite the entire bioperl library in an incompatible
but clear way? This is like the kind of weeding where you burn the lawn
and start over with that blue spray seed stuff. Fortunately for us we
have cvs, so we can keep the old lawn around until the new one is
totally grown up shiny and pristine, and even forever if we want. The
many people out there who are terrified of bioperl changing can rest
assured that their scripts will continue to work, etc., while a few
intrepid coders can work on luring them to the new lawn with the
refactored library's simplicity and ease-of-use. Onward, to greener
pastures! Bioperl 2.0!
Hilmar Lapp wrote:
> On Wednesday, June 18, 2003, at 02:59 PM, Chris Mungall wrote:
>> I call:
>> Which is in the pod docs for SeqFeature::Generic, and I don't think
>> it is
>> in any interface. So the point remains, SeqFeature::Generic is a
>> completely hidden implementation class, yet I am violating the
>> contract by calling add_SeqFeature on it.
>> Maybe this is deliberate? Maybe features are meant to be immutable with
>> respect to nesting?
> They aren't meant to be, but they can opt to be. This is reflected by
> absence of mutating method signatures in the interfaces. If you look
> closely you will also notice that the scalar getters don't
> specifically say that they will set the property if you pass an argument.
> I'm happy to support a proposal to make this more obvious / have a
> better convention, including foregoing altogether immutable objects.
> Others may have different opinions though.
>> you mean "Bio::SeqFeatureI implements get_SeqFeatures()" I think; but
>> point taken. I have definitely been confused by something.
>> the variety of method names for one thing eg - sub_SeqFeature
>> the fact that the same signature seems to be shared amongst multiple
>> SeqI (which ISA FeatureHolderI)
> I suggested to make SeqI a feature holder because the whole point of
> SeqI over PrimarySeqI is to add features and annotation bundles. I.e.,
> SeqIs that don't permit features to be added doesn't make sense to me.
> get_all_SeqFeatures is the feature tree flattened out
>> (are these copied and pasted from FeatureHolderI or are they the actual
>> (but no get_all_Seqfeatures)
>> And nothing for modifying the list of 'sub' SeqFeatures
> see above. Please propose a new convention that you think makes better
> sense for how to include or not include mutability into the contracts.
> The present one isn't good I agree.
>> I was also confusing myself by looking at:
>> So I retract, the contracts are not wrong. It's just it drives me insane
>> trying to read them.
>> There is still the one outstanding question of adding seq features
>>> sub_SeqFeature() must die!
>> Bioperl-l mailing list
>> Bioperl-l at portal.open-bio.org
| o-o Paul T. Edlefsen
| o---o Computational Biologist
| o----o mailto:paul at systemsbiology.org
| O----O Institute for Systems Biology
| 0--o 1441 North 34th Street
| O Seattle, Washington 98103-8904
| o-o callto:1-206-732-1336
More information about the Bioperl-l