[Bioperl-l] Bio::SeqFeatureI issues

[Hilmar Lapp]

> -----Original Message-----
> From: Ewan Birney [mailto:birney@ebi.ac.uk]
> Sent: Thursday, September 26, 2002 1:28 AM
> To: Hilmar Lapp
> Cc: Bioperl
> Subject: Re: [Bioperl-l] Bio::SeqFeatureI issues
> 
> 
> 
> 
> On Wed, 25 Sep 2002, Hilmar Lapp wrote:
> 
> > Neither seqname() nor seq() nor entire_seq() are on SeqFeatureI, but
> > I'm sure are used all over the place as if they were (in fact, they
> > are even used in decorating methods on SeqFeatureI).
> 
> I thought all three were in SeqFeatureI - these should be for sure.


OK I'll fix this.

> 
> >
> > Somehow we've got used to treat everything in SeqFeature::Generic as
> > present in every implementation of SeqFeatureI ...
> >
> > Not good. I suggest to promote all three to Bio::SeqFeatureI.
> > Similarly, attach_seq() should also be promoted. Anyone got
> > objections, or has anyone thoughts why this may be a bad idea?
> >
> 
> attach_seq() i think is about object creation/modification, and so is
> implementation specific. Do you think it has to be in the interface?

It's not object creation really - rather about associating the feature with another object. Having this on the interface underscores that in general features will live in association with sequences, and here is your method to express where it lives. I.e., implementors are encouraged to enable this association.

I think this bias is OK because it reflects 75% or more of use cases. Associating a sequence is still optional, so you don't have to call the method, and the implementor may choose not do anything useful when taking the call, and the SeqFeatureI doc can clearly state this. But I'd rather save $feat->can('attach_seq') a million times than not burdening an implementor with providing an empty implementation.

	-hilmar