[Biojava-l] The hierarchical ChangeTypes are on the trunk

Thomas Down td2@sanger.ac.uk
Wed, 7 Mar 2001 12:27:33 +0000


As promised last week, I've committed a patch which makes
ChangeType object hierarchical.  You can now build a tree
of ChangeTypes, rooted at ChangeType.UNKNOWN.  Listening for
any specific ChangeType will also catch any subtypes.

The code I've checked in is more-or-less exactly as initially
proposed, except that instead of exposing the immediate parent
of a ChangeType, we give an Iterator returning self and all
parent types (in order).  Thanks for Eric Blossom for this
suggestion.

The hope is that this patch will be pretty much transparent
in normal use.  All the ChangeTypes which were there previously
are still there as immediate children of ChangeType.UNKNOWN.  But
future ChangeTypes might end up as children of existing types.

For event sources:

  When firing events to your listeners, you now need to use
  ChangeType.isMatchingType rather than simple equality as
  a test.  However, right now I think all event sources are
  using ChangeSupport to fire their events, so I doubt if any
  more code will have to change.

For code which registers event listeners

  Right now, the API for registering event listeners is exactly
  the same as before, except that you can now register a listener
  for all types by doing:

      someObj.addChangeListener(myListener, ChangeType.UNKNOWN);

  this is exactly equivalent to using the one-arg addChangeListener.

  It's possible that there may be one or two bits of code which
  do:

      someObj.addChangeListener(myListener, null);

  This was never the right thing to do, but it did previously
  work as an equivalent to using the one-arg addChangeListener.
  This usage will now throw an Error -- if you see one of these,
  just change the null to a ChangeType.UNKNOWN


In the future, we have an option to remove the one-arg
addChangeListener completely, and require code which needs
to see all events to use ChangeType.UNKNOWN instead.  I'd be
interested to hear views on whether or not this is a good idea.
In the mean time, I encourage people to use ChangeType.UNKNOWN
in new code.



Hope this proves useful,

   Thomas.