[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.technology.equinox] Re: Separating concerns...
Jeff McAffer wrote: 
Mel,

I don't think you are missing anything.  Of course directing events to those
most interested can be a good thing. The usecases I refer to is where the
description, maintenance and management of "interest" is not
straightforward.  In the UI case, UI frameworks allow you to listen for
relatively simple events (mouse clicks, key presses, moves, ...).  These are
easily filtered, copied, described and so are easily directed to particular
listeners.

The UI frameworks generally do not allow you to receive notification only
when, for example, the right-shift is down and the click is in the title bar
of a window whose label is...  Rather, you listen for the base events and
then synthesize the rest.  Clearly you will get more notifications than you
want but that is the trade off.


The difference here is that the events parse and the potential # listeners for a given 'class' of GUI events is typically from a bounded set. A button event handler only has a few states to parse when dealing with a button event' and thus it's "filter" will be overhead on only a few calls compared to the scenario where it needed to filter on all GUI events. By partitioning mouse events from, say, a window event, we reduce both the work involved by the listener's filter and also the number of potential listeners whose filters will get invoked.

So yes, it is a trade-off on where you draw your lines to make distinctions, and I agree that when you can't you might as well let the listener do it's own filtering. And some filtering can only be done dynamically, at event time. Still good design should try to partition the event types in some manner to reduce both the number of listeners involved for each event notification as well as the amount of work each listener is responsible for.

Mel