[Bioperl-l] Bio::FeatureHolderI interface confusion

[Paul Edlefsen]

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!

:Paul

Hilmar Lapp wrote:

>
> On Wednesday, June 18, 2003, at 02:59  PM, Chris Mungall wrote:
>
>> I call:
>>
>>   $sf->add_SeqFeature(...)
>>
>> 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 
>> SeqFeatureI
>> 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
>> interfaces
>>
>> FeatureHolderI
>>
>>     get_SeqFeatures
>>     get_all_SeqFeatures
>>
>> 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_SeqFeatures
>>     get_all_SeqFeatures
>>
>
> get_all_SeqFeatures is the feature tree flattened out
>
>> (are these copied and pasted from FeatureHolderI or are they the actual
>> interface?)
>>
>> SeqFeatureI
>>
>>     get_SeqFeatures
>>     (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.
>
>     -hilmar
>
>> I was also confusing myself by looking at:
>>
>> CollectionI
>>
>>     add_features
>>     features
>>
>> 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!
>>>
>>> Lincoln
>>>
>>>
>>
>> _______________________________________________
>> Bioperl-l mailing list
>> Bioperl-l at portal.open-bio.org
>> http://portal.open-bio.org/mailman/listinfo/bioperl-l
>>
>>

-- 
+-----O------------------------------------+
|    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
+-o---o------------------------------------+