[Bioperl-l] Bio::FeatureHolderI interface confusion

Chris Mungall cjm at fruitfly.org
Wed Jun 18 14:22:38 EDT 2003


On Wed, 18 Jun 2003, Lincoln Stein wrote:

> To answer Chris's question, the current interface would require you to:
>
> 	1) open a Bio::SeqFeatureIO
> 	2) fetch a Bio::SeqI from it
> 	3) call Bio::SeqI->get_SeqFeatures to get one or more Bio::SeqFeatureI's
> 	4) for each Bio::SeqFeatureI, you can rely on them to respond
> 		to the sub_SeqFeatures() call, although they usually will
> 		usually return an empty list
>
> Maybe I'm missing the point of the discussion, but there's no violation of the
> contract here, and this is what Chris is asking for.  No need to call isa()
> or can().

Step 4 is a violation; where in the Bio::SeqFeatureI code or documentation
does it state that you can use the method sub_SeqFeatures()?

You said: "you can rely on them to respond to the sub_SeqFeatures() call"

Yes, I can rely on them to do this purely because I cheated and I ignored
the contract and saw that the implementing class is
Bio::SeqFeature::Generic

Step 4 would not be a contract violation if Bio::SeqFeatureI inherited
from Bio::FeatureHolderI - it does not.

Yes, I can do a test:

  if ($sf->isa("Bio::FeatureHolderI")) {
    $sf->add_SeqFeature($foo);
  }
  else {
    $self->throw("feature does not have ability to hold subfeatures");
  }

But where in the pod docs or @ISAs does it even give the slightest hint
that the SeqFeatureIs that come from SeqI might possibly be
FeatureHolderIs? The code snippet above is completely lacking in logic,
unless you have prior knowledge beyond the contracts.

> Lincoln

Chris



More information about the Bioperl-l mailing list