The TreeModel listener registration could be improved.

The modelview pkg divides the model into four
interfaces, TreeModel,
NodeModel, NodeActionsProvider and TableModel.
Each interface
dictates that TreeModelListener listeners be
registered.

The client can utilize these interfacse in one of
two ways.
a) create subclasses for each interface (all four
or only the ones they need)
b) create one subclass that implemets all interfaces.

The TreeModelListener registration is driven from
within debuggercore via
CompountModel.addTreeModelListener():

    public void addTreeModelListener
(TreeModelListener l) {
        treeModel.addTreeModelListener (l);
        if (nodeModel != null)
            nodeModel.addTreeModelListener (l);
        if (nodeActionsProvider != null)
           
nodeActionsProvider.addTreeModelListener (l);
        if (tableModel != null)
            tableModel.addTreeModelListener (l);
    }

This implementation is sub-par from a performance
POV for both use cases.

In case (a) the same listener is recorded for four
distinct sub-model
implementations. This doesn't make sense since one
would expect that
the listener for the treemodel be a callback that
affects only
tree-like properties, and that the listener for
the actions provider
be one that affects only the actions. But from the
above code it seems
that one callback is used for everything. The
result is that the
hapless client will call the listener from each
sub-model and the same
callback will be called redundantly.

In case (b) there is one model implementation but
the same listener
gets registered with it, redundantly, four times.
So whenever my model
changes I end up calling tree[Node]Changed() four
times which cause
countless pulls from the model and who knows how
many view refreshes.
(Not to mention that debugging becomes very tedious).

-----------------------------------------------------------------

A natural solution to the (a) scenario is to have
4 distinct callbacks
and listeners.

A solution to (b) that comes to mind is as
following, although
it's hard to see how it could be extended to deal
with (a) efficiently.

    public void addTreeModelListener
(TreeModelListener l) {
        treeModel.addTreeModelListener (l);

        if (nodeModel != null && (nodeModel !=
treeModel))
            nodeModel.addTreeModelListener (l);

        if (nodeActionsProvider != null &&
(nodeActionsProvider != nodeModel &&
                                           
nodeActionsProvider != treeModel))
           
nodeActionsProvider.addTreeModelListener (l);

        if (tableModel != null && (tableModel !=
nodeActionsProvider) &&
                                   tableModel !=
nodeModel &&
                                   tableModel !=
treeModel))
            tableModel.addTreeModelListener (l);
    }
~
~