[Biojava-l] Immutable objects and ChangeListeners

[Thomas Down]

On Tue, Jan 09, 2001 at 06:49:05PM -0500, Forsch, Dan wrote:
> I like the listener/event paradigm which is extremely common in "modern"
> Java programming.  Observer/Observable is lightweight but it doesn't provide
> enough semantics.
> 
> However, I think Mark raises a fair question which I would recast thusly:
> does BioJava need its own change notification API when mechanisms for this
> already exist in the core Java libraries?  I'm thinking specifically of the
> beans PropertyChange classes.  BioJava's ChangeEvent stuff has some nice
> features like the ALWAYS_VETO listener and the ChangeForwarder mechanism for
> chaining change events.  It also unifies the bound and constrained
> properties into one change framework which I feel makes it a somewhat better
> API than PropertyChange/VetoableChange.  
> 
> Even so it replicates about 75% of what's already built into Java as a
> standard API which makes BioJava less compatible with external code,
> especially (but not limited to) GUI apps and JavaBeans.  I believe it would
> have been possible to add some of the ChangeEvent features as extensions to
> PropertyChange.  The result might have been a little less clean and somewhat
> constrained (heh) in terms of functionality but it would have gone a long
> way to making BioJava compatible with Java standards.
> 
> I'm interested in hearing others thoughts on this with the possiblility of
> looking to move the changeable support to an extension of
> PropertyChange/VetoableChange following the 1.1 release.

The main problem with the `javabeans' style change events is
that they are tied to properties.  This works quite well for
the job of GUI-building many kinds of applications (which is
what javabeans was originally intended for, I guess), but it's
kind-of limiting.  For instance, how do you represent a change
in the weights of a Distribution?  These aren't properties in
the javabeans sense (each individual weight doesn't have it's
own accessor and mutator methods), but they are still very real
`properties' of the object, and it's useful to include them in
the event framework.

The same is true (probably more so) for Edits applied to 
SymbolLists.

Sun have gone some way to recognising that you need a change
framework which goes beyond javebeans-style properties.  Look
at javax.swing.event.ChangeEvent.  In some ways, this is
closer to the BioJava events than the java.beans ones are.
But it's very simplistic.  The BioJava events are a pragmatic
attempt to build a system that fits the requirements for
bioinformatics applications (I suspect it might also be useful
in other cases).

There's probably more that can be done, though.  I particular,
some simple adaptor classes to bridge between the BioJava
and JavaBeans event models would be useful, especially when
working with beans-aware GUI components.

> 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.)

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