delegate-based event system

[Byron]

Currently it's quite common in bcore to use delegation as a mechanism to delegate functionality to different implementations. These implementations are usually provided as plugin as part of the context.

Compared to signal-slot mechanisms, delegates may additionally provide return values, may interrupt calls through exceptions, and work without an intermediate queue. However, this must be the case only if the delegate call is expected to have a return value. In any other case, it's very similar to a signal which can be handled in any way under the hood.

The delegate mechanism also forces clients to implement an entire interface, even though they are only interested in a single signal. Nonetheless, through derivation from a standard implementation, one can easily bring down the boiler plate to a class with as much as a single implemented method.

Thanks to instantiation, delegates may have state, and implementors have more context as they see it as a whole.

What's an advantage can also be a disadvantage, and it's clear that individual signal-slot based events are very granular, and thus potentially more flexible to use.

Also, in the Signal-Slot case, the client chooses which signal to connect to, whereas in this case, control over which delegates are fed is purely in the hands of the implementor.

Possible Applications

• ProcessController
  • support for chained delegates, allowing to specify them where they belong
• sg-events
  • The entire daemon is essentially a dispatcher of calls, which can easily be implemented using such an event system as base.

Required Features

• A template interface should be given which allows to specify per-method (class/instance) definition of
  • how to aggregate return values
  • how to implement reduce-like behaviour, feeding output of one delegate to the input of another.
  • support for one or many delegates
  • whether or not only implemented methods should be called (as to prevent calling a base implementation)
  • How to handle errors (catch all and raise when all calls are done. Raise on first exception ? Log and ignore ?)
• It must be customizable how delegates are retrieved. Default should be to use the specified context. Should these be forced to be stateless ? Are their instances kept between calls ?
  • Order of delegate calls should be controllable that way
• (A way to identify a base implementation)
  • Otherwise, if chained calls are possible, the same base implementation would be called multiple times. Maybe this isn't required anyway, as such methods simply shouldn't be chained at all