[Biojava-l] Immutability as a default

[Forsch, Dan]

> -----Original Message-----
> From: Thomas Down [mailto:td2@sanger.ac.uk]
> Sent: Wednesday, January 10, 2001 3:15 AM
> To: Forsch, Dan
> Cc: 'Mark Schreiber'; Matthew Pocock; biojava-l@biojava.org
> Subject: Re: [Biojava-l] Immutable objects and ChangeListeners
> 
> > I was further wondering if some of the "missing" implementations of
> > Changeable, particularly in some of the Simple... 
> implementations like
> > SimpleSequence, should be filled in.  Is there any support 
> for adding this
> > to the To Do list for 1.1?
> 
> What do you mean by `missing'?  If an object really is immutable,
> then it's fine for it to have a stub Changeable implementation.
> 
> On the other hand, there are also some objects which aren't
> quite immutable as they seem (usually because they are 
> Annotatable, and the annotation can change), and we should
> certainly look into fixing those ASAP. (I think I have to
> take some of the blame for these -- oops.)

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?

I haven't seen any cases of immutable objects which are really mutable but I
belive I found one bug related to mutability.  It's evident in the following
code:

            ViewSequence view = new ViewSequence(someSequence);
            Annotation annot = view.getAnnotation();
            annot.addChangeListener(ChangeListener.LOG_TO_OUT,
Annotation.PROPERTY);
	try {
                annot.setProperty("Dummy", "Value");
            }
            catch (ChangeVetoException cve) {
            }

The above results in: java.util.NoSuchElementException: Property Dummy
unknown

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
throws NoSuchElementException for unknown keys.  

A possible solution is to have OverlayAnnotation catch the exception and
just return null.  What I think would be better is to not throw a
NoSuchElementException in getProperty because it is a RuntimeException which
the compiler doesn't force you to catch even if it's declared using
"throws".  My preference would to change the semantics of
Annotation.getProperty() to return null when an unknown key is requested.

I'd make a fix myself but I don't have write access to CVS.

Dan Forsch, Principal Software Engineer
NetGenics, Inc.
1717 East 9th Street, #1600
Cleveland, OH  44114
phone: 206.374.4541