[Biojava-l] Updateable Sequence; BioJava's view

[Thomas Down]

On Thu, Oct 25, 2001 at 10:44:16PM +0100, Ewan Birney wrote:
> 
> Over on Bioperl we having the start of a discussion about Updateable
> sequences.
>
>   (a) do you have a ReadOnly interface and a ReadWriteInterface or just
> one interface?

No, we thought about this, but decided that there was too
much cause for confusion -- espcially once you start having
`view' objects, which can wrap some other object which might
be mutable or immutable.

Immutable implementations of potentially-mutable interfaces
throw ChangeVetoException for all calls to mutator methods.

>   (b) in the updatable interface, are all possible updates allowed?

That's implementation defined, so I guess the answer is
no.

>   (c) updates cause events to be thrown (right?) Does every updatable
> object therefore have the ability to register for listeners or is there an
> implicitly global event channel?

Yes, every updatable object does (or at least should) implement
the Changeable interface, which defines add/removeChangeListener.
Obviously, for an immutable implementation, these methods can
just be empty stubs.

>   (d) how much do implementations share - is there a read-only
> implementation? Does it share any code with a read/write?

In the specific case of SymbolList, yes there is some code
shared between the varous implementations we have lying
around -- most of these extend AbstractSymbolList.  Whether
or not this is worth doing depends very much on the detals
of your implementation -- don't think there are really any
hard-and-fast rules here.

>   (e) if you haven't separated out read/write from readonly has anyone got
> burnt by an update happening behind the scenes?

I hope not.  Actually, our mutable SymbolLists are pretty
new (although the interfaces have supported mutability for
a while, there wasn't a mutable implementation for some time).
But in the case of other mutable objects, things generally seem
to have panned out pretty well.  In particular, we make it easy
to do something like:

   mySeq.addChangeListener(ChangeListener.ALWAYS_VETO, ChangeType.UNKNOWN);
   // code which can't cope with changes.
   mySeq.removeChangeListener(...);

Those extra two lines give belt-and-braces security, irrespective
of the implementation you're dealing with.

Hope this gives you some pointers, anyway,

     Thomas.