[Biojava-l] Immutability as a default

[Thomas Down]

On Mon, Jan 15, 2001 at 12:35:17PM -0500, Forsch, Dan wrote:
> 
> I agree that an empty Changeable implementation satisfies the contract for
> an object which is always immutable.  I guess I need to rephrase my question
> and ask why many of the concrete implementations of BioJava interfaces
> (Simple...) would be immutable by default.  As previously highlighted, it's
> easy to 'lock' an instance of a changeable value with an AlwaysVetoListener
> but it's not possible go in the reverse direction if the Changeable
> interface is no-oped.  Put another way, couldn't mutability be a runtime
> object-wise issue rather than a compile-time class-wise one?

The point of specifying just about everything as interfaces (as
we do in BioJava), is so that we can have multiple implementations
optimized for specific purposes.  Sometimes, and immutable implementation
of an interface is potentially more efficient for the common (read-only)
case than an implementation which handles mutability gracefully.  This
is the `good' explanation for immutable-by-default implementations (The
not-so-good explanation is, of course, that the mutable implementation
is harder to write and nobody needs it yet).

The main (almost-)immutable-by-default object which comes to mind is
SimpleSymbolList.  This used to be a really important class since
these were being created by the I/O framework, and we wanted them
to be simple, reliable, and as fast as possible for the read-only
case.  Now the I/O framework is using it's own SymbolList implementations
99% of the time, so this argument no longer holds.

I'd agree that, as a general principle, the `Simple' implementations
should be complete, and that includes mutability support.  If nobody
else wants to take this on, I'll replace SimpleSymbolList with a new
implementation which is truly mutable.

> [snip]
>
> The problem is that OverlayAnnotation is calling getProperty() from
> setProperty() to get the old value for the ChangeEvent.  The former in turn
> ends up calling parent.getProperty() if the key is new, but SimpleAnnotation

Yeah, this is a bug which slipped in when we added the Changeable
support for this class -- it's fixed now.

Sorry about that,

   Thomas.
-- 
``If I was going to carry a large axe on my back to a diplomatic
function I think I'd want it glittery too.''
           -- Terry Pratchett