Re: boost::function syntax

From: Edward Diener (eddielee_at_[hidden])
Date: 2003-08-26 22:12:19

shyamemani wrote:
> So combining this response with your response to Edward regarding
> standardization of boost.signal, shouldn't this be a big concern,
> since the use-case which I illustrated is quite commonly used in
> event based systems?

No, it is not common to want to have a single event handler for events with
different signatures. Or to register different event handlers for separate
events all with one call. What you are doing is saying that you have these
needs, and because a library doesn't fulfill them for you, let's have a
language extension to solve your special case.

The normal event-handler paradigm is that:

1) a single event handler handles a single event
2) an event may have more than one event handler
3) an event handler may handle more than one event, if and only if, the
signature for the event handler is exactly the same for different events and
there is a way of telling which one of the events has occurred in the event
handler.

When you want to go outside this basic paradigm, it is up to you to write
code to do so, not for libraries to change merely to accomodate your needs.
That doesn't mean you can't suggest additions to libraries which you feel
are in the realm of event handling, but you must justify them as being
worthwhile not just for you but for programmers in general. Or else create
your own library to solve your own problem and perhaps others.

>
>       But if this can be ironed out I think providing it as a
> language extension is better because then C++ can become a language
> which has built-in semantics for  use of the standard design
> patterns.  And then we programmar's and designers can live happily
> ever after ....

Built-in semantics can be just as limiting, for your needs, as a library and
provide no guarantee of happiness. In general, in a case where both a
library and a language extension can provide the same solution to some
programming paradigm in C++, the most important case for a language addition
is, IMHO, ease of programming use. In general it is much better, because
more flexible, to extend a language via libraries than adding language
extensions.

With all that said, having used a language extension for many years which
provides event handling to C++, Borland's __closure, and most recently
Microsoft's __event and __delegate extensions, I am very much for either
adding Mr. Gregor's excellent Boost.Signals in some close form to the C++
standard library, or adding a language extension patterned after the
Microsoft and/or Borland solutions to the C++ standard language.

However, none of these solve your particular event programming model which I
find a very weird and overly complicated design. There is no need in a good
event-handler model, such as Boost.Signals, for handlers to derive from a
class which represents the events to be handled. Nor do events to be handled
need to be virtual.

If you take a look at Boost.Signals, and study how it works, you will see
that the event and the event handler are only dependent on the signature of
the event to be handled, and nothing else really. As long as you have an
appropriate signature to handle the event, you can bind to it with any
appropriate handler, most particularly member functions of any object's
class. I don't think you appreciate yet why this model is so superior to
yours as far as ease of use is concerned. The whole idea of a good
event-handler model is that the event be coupled as lightly as possible to
the event's handlers. This is what Mr. Gregor achieves in his library and
also what the Borland and Microsoft extensions also achieve in their own
different ways. There is no need to enforce particular derivations or
virtual functions in these models.