[news.eclipse.technology.equinox] Re: Separating concerns...

[Mel Martinez <melm@xxxxxxxxxx>]

Jeff McAffer wrote:
> "Mel Martinez" <melm@xxxxxxxxxx> wrote in message
> news:b6ae1j$5sm$1@xxxxxxxxxxxxxxxx
>  
>
> > 2) the granularity of the messaging.  Are you saying that for every
> > registry event you would prefer to broadcast that to every listener?
> > Doesn't that become problematic in the hypothetical 5000 plugin case?
> > If there are only two or three plugins that are actually affected by an
> > event, it is really inefficient to make 5000 calls that each have to
> > examine the delta to see if it is of concern before no-op'ing.  One
> > badly written plugin could slow up the processing of EVERY event!  Maybe
> > I'm misunderstanding you here.
>
>
> Yes. but (there has to be one :-) the 5000 plugin case is for 5000
> *installed* plugins.  Not 5000 *active* plugins.  You only need to notify
> active plugins.  Even still processing the changes for 300 active plugins
> could be non-trivial.  Plugin writers should follow Pascal's advice and
> no-op early and the runtime can likely provide mechanisms to help them do
> that (as we do in other places in Eclipse).

Why is this preferable to them just not registering to recieve the event 
in the first place?

Isn't this analogous to having every GUI event in an app sent to every 
event handler and requiring each such handler to filter to identify just 
the events it is interested in?  I.E. even if I'm only interested in 
events generated by a particular button, I have to recieve and filter 
all other events:

public class MyButtonHandler{
 ...
 theApp.registerForALLEvents(this);
 ...
 public void doEvent(Event e){
  if(isMyButtonEvent(e)){   //<-- I am forced to examine every event
   ...do stuff
  }
 }
}

I'd have thought it pretty well accepted that it is preferable to 
pre-filter by only registering to recieve those events that one is 
interested in.

public class MyButtonHandler{
 ...
 theButton.registerForEvents(this);
// or theApp.registerForButtonEvents(this);
 ...
 public void doEvent(Event e){
  ...do stuff...
 }
}

The former model is well-recognized as not scaling, is more vulnerable 
to bad programmer mistakes (since it asks more of the programmer) and 
since more parties are involved with every event notification more 
susceptable to cyclic dependency problems.  The latter model scales very 
well, asks less of each handler programmer and since fewer participants 
are involved on each notification decreases the chance of cyclic 
dependencies.


> > My preference would be to send deltas to just the parties that are
> > registered to listen for events on that registry item.
>
>
> I actually agree with this but every time we have tried to implement such a
> mechanism, it turns out to be more complicated to manage and run both from a
> mechanism and user point of view.

Could you explain or give an example of what you mean here?  I'm really 
struggling with trying to understand why you and Pascal are advocating 
this design (notifying all listeners of all events as opposed to just 
notifying those listeners registered to listen for events on particular 
parts of the registry).  I allow that I am missing something, but it is 
not yet obvious to me.