[Biojava-l] changed (improved) SequenceDB and stuff

[Gerald Loeffler]

hilmar.lapp@pharma.Novartis.com wrote:
> 
> > Though minor in nature, the addition of the getName() method to
> > interface SequenceDB will result in all implementations (outside the
> > BioJava distribution) of this interface to break in the sense that they
> > will all have to add an implementation of the getName() method...
> >
...
>      To make a long story short, what I wanted to suggest is, why not have an
>      interface NamedSequenceDB which inherits from SequenceDB, and everyone is
>      fine to have his SequenceDB implementation be a named one. There are a lot
>      of cases where you simply don't need a name, and the fact that it hasn't
>      been there until now at least doesn't disprove this.

you're absolutely right - i thought about doing exactly this (even using
the same interface name) but dismissed it because i guessed (wrongly, it
seems) that directly implementing SequenceDB (as opposed to using one of
the supplied concrete implementations of SequenceDB) would not be too
common (although i'm doing this right now (-:).

Anyways, as much as i'd hate to see an incompatible change like this
happen in (lets say) one of the java.* packages, i'm not sure whether we
should be so strict about BioJava. Absolutely prohibiting incompatible
changes in BioJava is probably a bit premature because it hinders what
is still a bit of a work-in-progress (definitely no offence intended,
Matthew!).

A possible way to manage change to the BioJava API could be to introduce
versioning and restrict incomptible changes to the (rare) increases in
the major version number. The symbol/seq-part of BioJava could be
designated 1.0 right now, and future incompatible changes (like the
ambiguity change or this db-naming change) may only occur in one go when
moving to 2.0....

	cheers,
	gerald

> 
>      What do you think?
> 
>           Hilmar

-- 
   Gerald.Loeffler@vienna.at _________________ Software Architect
   http://www.imp.univie.ac.at ____ http://www.daemonstration.com
   OOA&D, Java, J2EE, JSP, Servlets, JavaBeans, ODBMS, RDBMS, XML