Re: [boost] SUBMISSION: Signal/slot library

From: Jens Maurer (jmaurer_at_[hidden])
Date: 2000-04-14 16:47:16

I would like to remind that the most important issues are
not those of implementation, but those of interface.
We should focus on the interface first and decide which
functionality we really need.  I do believe in
minimality of interface.

Competition of implementations with identical interface is
good, cf. the various Standard Library implementations.

With the lambda library, we have a concept orthogonal
to the signal/slot mechanism.  Another message in this
thread says they're working fine together.
In conclusion, this reduces a signal/slot library to
providing a type-independent storage and execution
device for a lambda library's expression template
objects.

Tomasz Kowalczyk wrote:
> - doing approximately the same, is about 5 times smaller,

Implementation issue. 

> - is exception safe,

The interface should require this.

> - contains headers only, there is no need for linking,

Implementation issue.

> - allows to easily connect to a signal anything that can be called as a
> function,

Since the advent of the lambda library, this is a non-issue.  The
availability of the lambda library also means that the "feature"
that "Slots can be called with the number of arguments equal or
greater than the number of arguments of their target." can be easily
abolished.  If the lambda library doesn't have an appropriate feature,
add it there instead of blowing up the signal/slot library.

> - allows to copy signal objects - you can store them in a container for
> example,

Interface consideration not yet settled, as I understand.

> - avoids circular references by not using reference counting for signal
> receivers,
> - has no casts in the implementation,
> - uses standard library where appropriate,

Implementation issues. I don't care if the implementation uses
casts or the standard library or raw C pointers as long as it
implements the advertised interface.

> - makes writing generic code easier by using consistent naming
> (signal<>, signal<A> vs Signal0<>, Signal1<A> etc.)
>
> To be fair, I have to write what you cannot find in my library:
> - signals returning values

These are interface issues which need discussion.

In my opinion, signals requiring a different number of parameters
should have different names (and also different types, of course).
This may not have optimum prettyness, but it allows for easier
scalability to more parameters.

I would like to see an interface specification acknowledging
the existence of a lambda library first.  Then, re-thinking
Tomasz Kowalczyk's implementation would probably dramatically cut
down the code size.

Jens Maurer.