Re: Re: Re: boost::function syntax

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

Douglas Gregor wrote:
> On Tuesday 26 August 2003 05:41 pm, Edward Diener wrote:
>> Is there a reason Boost.Signals wasn't submitted for TR1 approval
>> other
>> than the worked involved doing so by writing up the necessary
>> submittal
>> form ?
>
> Yes, there's a reason: Signals isn't ready for standardization. It
> hasn't been
> around long enough for us to be sure we have the right interface, nor
> is it
> small enough that we can say "yep, that's the right interface." More
> specifically, there are some parts of the interface that I don't
> believe are
> entirely correct, including:
>
> 1) Combiners and the slot_call_iterator: I think the interface is
> correct (although the implementation is very complex), but we can't
> say for sure that
> it was worth the effort.

The complex implementation shouldn't be a bar to it being used. It provides
a means of handling all return values as the signal sees fit. I think it is
brilliant. It's a slightly complicated issue for the designer of the event
and not the event handlers, who just return the appropriate value, and that
is how things should be.

> 2) Slot ordering, groups, and naming: I'm pretty sure we have this
> wrong, but
> I don't know what's better. Most applications could do with a simple
> linked
> list of slots, that are called in the order they are connected; a few
> more
> apps would benefit from the ability to connect to the front or back
> of the
> list; but there don't seem to be many apps that actually need the
> ordering &
> naming that Signals provides.

I agree that this could be provided with a different general purpose
mechanism for determining the order in which signals are called. If I think
of anything brilliant myself, or even mildly interesting <g>, I will convey
it to you.

> 3) Trackability: there's a general tracking interface here that would
> be
> really useful, but I haven't had the time to pull it out.

Yes, it seems that requiring a class to be derived from a particular class
to be trackable might be too much coupling. But it works and should be
little problem considering C++'s multiple derivation ability. I can't think
of a better way offhand to do it. Somehow the object which contains the slot
must tell the signal whether it is still alive or not.

> 4) Multithreading: this isn't much of a concern for the standard
> right now,
> but without a solid multithreaded implementation I don't want to try
> to
> standardize the interface for fear that it may not allow a good
> multithreaded
> implementation.

I don't see how Boost.Signals can or should take into account
multi-threading issues, but I am sure you have thought long and hard about
this regarding situations of which I have no awareness. I have a gut feeling
that multi-threading issues must be solved by either a separate C++ library,
like Boost.Threads, or by the language itself, and should not be the domain
of every other implementation.

>
>> I would very much like to see the C++ standard library adopt a
>> common event handling interface, whether through a library such as
>> yours or
>> an extension to the language ( such as Borland's __closure pointer ).
>> Handling events in a common way, and especially allowing both events
>> and
>> handlers ( signals and slots ) to be free of specific class
>> limitations,
>> will move C++ much closer to a modern paradigm which I find
>> invaluable in
>> using the language.
>
> I agree that it would be very useful to have a common event handling
> interface, although I firmly believe it should come in the form of a
> library
> and not via a language extension. I'll be happy to propose Signals
> when I
> think we've hammered out the existing problems.

I hope you do. C++ needs to move more solidly into the present paradigms of
programming, and event handling as a language/library interface has become,
at least for me, almost ubiquitous with effective modern day programming
practices. Of course I also like the "property" idea, in the
property/method/event programming model, but I have found it is fruitless to
argue with others about it since the resistance to syntactical sugar, no
matter how elegant it may be, is ingrained in most C++ programmers. But
events serve a much deeper purpose which makes programming itself much
easier and clearer.