[Bioperl-l] RE: Bio::FeatureHolderI interface confusion

[Ewan Birney]

People might be surprised to find me agreeing with nat - but also I think
there is a deeper design shift happening:


  Chris,Nat and I want interfaces *only* to be of relevance to client code
(ie, scripts and very distantly maintained other object code), and there
should be a (small) list of interfaces which encompass all that you need
to know about what objects bioperl produces, with implementations
magically conforming to them and producing different objects. I feel ---
as probably does Chris --- that actually it is only this set of interfaces
that you have to be tied to; everything else is pretty moveable.

  (My set of core interfaces are Bio::SeqI, Bio::SeqFeatureI,
Bio::DB::RandomAccessI, Bio::SeqIO, Bio::SearchIO and friends,
Bio::AnnotationCollectionI - which I admit is a bad name - and
Bio::AnnotationI)


  Hilmar and others like him like interfaces being using inside of
Bioperl development to make explicit what developers are promising
and how things should be stuck together. Many "micro" interfaces are a
good thing here.

  Any language has this push-pull tension going on, and there are
a variety of conventions and/or formalisms to deal with this

  As Perl doesn't have "interfaces" in a standard way so we just have
to agree on conventions inside Bioperl. I personally think that a
good way to go is:

   ---> xxxxxI.pm implies this is a public interface and should be
maintained for backward compatibility for as long as possible. Unlike Nat,
I think we do quite a good job for backward compatibility over releases
with the core interfaces not changing in about 2 years now. The only issue
is probably the BLAST parsing stuff which has 3 parallel development
tracks which only recently we have managed to unify in Bio::SearchIO.

   ---> other contracts are documented as a series of methods which
can be swapped in or out by other modules wanting to fullfill this role,
without having a formal I file.


  - this is mainly because developers are more tolerant about having to
dig around in documentation, and in any case are likely to want to read
the different code implmentations anyway, whereas clients want to have
strict interfaces "whenver I can a Bio::SeqI, I can always do xxxx"



Anyway - this is a convention that we should agree on. My proposal is
to strip bioperl of the developer style interfaces, and strengthen
the client style interfaces.



ewan