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