Standard Event Driven Object Library for D

[Christopher Wright]

Brian White wrote:
> As an example...
> 
> - An EvThread instance does a select and eventually gets a read event on 
> path #N.  It does some work and then calls handler.PathReadHandler(pathno).
> 
> - The EvSocket object that was called as a result does some processing 
> and eventually calls handler.SocketReadHandler(this).
> 
> - The EvSocketStream object that was called as a result does some 
> processing and eventually calls handler.SocketStreamReadHandler(this);
> 
> - The EvHttpServer object that was called as a result reads the pending 
> data, does its magic, writes a result, and returns "true" to say it 
> handled the event and wants more of them.
> 
> - The EvSocketStream object thinks all is good in the world and also 
> returns "true".
> 
> - The EvSocket object thinks all is good in the world and also returns 
> "true".
> 
> - The EvThread object things all is good in the world and starts another 
> select loop.
> 
> Had the event not been handled (returned "false"), it would have 
> disabled read events on that path and continued on.
> 
> -- Brian

I'm seeing two types of events: notifications and responsibilities.

A notification just says "This happened, and I don't care if anyone 
reacts to it." std.signals does okay with that, except for a few bits of 
ugliness and the fact that it places undesirable dependencies between 
objects.

A responsibility says "This happened, and someone (but only one) should 
take care of it." It might be an error if nobody handles it. Something 
can take a look at a responsibility before determining that it's 
somebody else's problem.

However, I don't see the utility in automatically removing a listener 
when it claims that it cannot handle a particular responsibility. Not 
handling a particular message and not handling any further messages are 
different use cases.