[Biojava-l] Proposal: ChangeType hierarchies (also event bridges)

[Thomas Down]

On Thu, Feb 22, 2001 at 12:48:49PM +0000, Matthew Pocock wrote:
> 
> >   - Add extra constructors to ChangeType objects which allow
> >     a parent to be specified.  If the current (no-parent)
> >     constructors are used, we default to ChangeType.UNKNOWN
> >     (which becomes the root of the type hierarchy).
> > 
> >     [Open issue: what is the value of ChangeType.UNKNOWN.getParent()?]
> 
> null, I think. Alternatively, it is its own parent (uck).

Yeah, I think null is a safer option than self.  Hopefully,
anyone who's traversing up the ChangeType chain will stop
when they hit ChangeType.UNKNOWN anyway.

> > Impact on current code would be minimal -- The only
> > place I can think of where any changes will be needed
> > is ChangeSupport.
> 
> We should also remove the add/removeChangeListener(listener) methods, 
> requiring add/removeChangeListener(listener, UNKNOWN) to be used instead.

I'm neutral on this one.  But it would tidy things up quite
a bit, and shouldn't be that much hassle if we address it now.

> Do we have the ChangeEvent -> bean property event bridge? This should be 
> an early priority for 1.2

Let's gather some requirements for these.  There are various things
which can be done to bridge between the two event models, but since
their semantics can be quite different at times, there are several
different bridging strategies:

  - The `mini-bridge'.  This is used for objects which have
    one (or more) properties which aree BioJava Changeables.
    These bridges are created and maintained by the container
    object.  Any changes to the containee are propogated as
    java-beans style events.  I believe the semantics of this
    case should be reasonably clean, but I don't know exactly
    how useful it would be.

  - The direct bridge.  These are built directly for Changeables,
    and expose all changes as beans-style events.  Listeners are
    registered for property names which are equal to the string
    representation of the BioJava ChangeType (or, more realistically,
    I'd guess that this would really just get used for listening
    to /any/ change, and repainting a GUI or whatever).

Does anyone think they might use either of these possible
event bridges?  Are there any other (better?) bridging
semantics which might be useful?

The bridge in the opposite direction (PropertyChangeEvent ->
ChangeEvent) is relatively easy to code, at least in the
simple case of just firing a special JAVA_PROPERTY ChangeType.
It does, however, run into the problem of not all `beans'
events being vetoable.  

Would anyone actually use this latter bridge if it did exist?

   Thomas.