Synapse library review result

The Decision
--- --------

There were a total of 9 people, outside of the library author Emil 
Dotchevski, who reviewed/commented about the Synapse library during the 
review period and the Monday following where I accepted a late review 
and people's responses to that late review.

The voting in the Synapse review is:

0 for YES
2 for NO, with one of the two a provisional NO.

Among the other people who commented but did not vote I have 2 people 
who said they definitely liked the library and 2 people who said they 
definitely did not like the library.

Among other commenters I interpreted 2 other people as probably 
approving of the library as it now is and 1 other person as probably not 
approving of the library as it now is.

Given the actual YES or NO vote, and the small amount of people who took 
part in the review, and the even smaller amount of people who decided to 
vote YES or NO for the library, the Synapse library is NOT accepted into 
Boost.

My decision as review manager is based on the review of the library by 
others and not on my own personal view of whether the library should be 
accepted or not.

Issues
------

I want to use the next part of this decision to summarize the issues 
brought up largely, but not exclusively, by those who did not see the 
Synapse library as currently being worthwhile to become a part of Boost. 
This issues I summarize below may or may not be seen as relevant or not 
by others but they do represent the areas of criticism of the library 
made during the review. All the issues were answered by Emil during the 
review, and I think he did an excellent job of answering reviewers based 
on how he sees these issues. Some of these issues may be seen as 
unimportant or trivial or already well answered, but I want to list them 
all nonetheless. The issues are presented in no particular order of 
importance. I will refrain from making my own comments about these 
issues until my own general summary at the end of this review decision:

1) The current Boost signals/signals2 library is adequate for 
signal/slot processing and another signal/slot library such as Synapse 
does not provide enough of a usage argument to be added to Boost along 
with what already exists.

2) The documentation needs to be more expansive on the difference 
between Boost signals/signals2 and the Synapse library.

3) The end-user should have some sort of control where Synapse stores 
its information regarding the connection between signal emitters and 
slots ( signals handlers ).

4) Since Synapse is a C++11 library it should use C++11 standard library 
constructs across the board rather than their Boost equivalents.

5) There should be some "natural" way in which slots can return a value, 
ala the signals2 library.

6) A more flexible way of handling the slot lifetimes should be created 
as an addition to the shared_ptr/weak_ptr way the library currently employs.

7) A means by which a particular thread can be specified ( 
thread-affinity ) for a particular slot when connected should be 
created; or a dispatching mechanism, perhaps using asio, for connecting 
a slot to an emitter.

8) The ability to have signals emitted with more than four parameters 
should be created.

9) The fact that emitters are identified strictly by address was seen as 
a weakness in the design since at least theoretically, if not very often 
practically, it is possible for two different variables to have the same 
address. Connected to this is that the address of emitters is noted with 
a "void *" in the public interface, and that was criticized
as not C++-like.

10) Connection objects should be movable rather than using shared_ptr.

11) The central dispatching mechanism is too slow for large scale 
continuous changes which emit signals to be handled by slots in some 
systems ( a stock market changes type of application was brought up as 
such an example ).

12) The use of only Boost function as a callable slot is too inflexible.

13) The signal type ( pointer to function whose return type identifies 
signals ) was seen both as cryptic and inflexible, and a deduced signal 
type was suggested.

14) Having more than one signal type in Boost in general was seen as a 
bad situation.

15) More specific information on which compilers should work with Synapse.

Summary
-------

First of all, thanks to everyone who participated in the review and for 
Emil for answering and providing explanations for his design and coding 
decisions. I cannot say it enough but I really hope that more people can 
be encouraged to look at libraries up for review and make comments, even 
if they do not want to make an official vote or comment on any 
particular area in which they do not feel they have adequate knowledge. 
All comments and personal or technical evaluations are important and 
help a review manager make a final decision, as well as telling a 
library author what others think of what he has done.

With that said I will not try to hide the fact that I personally view 
the Synapse approach to signal/slot processing as different enough, and 
useful enough due to its non-intrusive nature, from signals/signals2 to 
be a valuable addition to Boost, even while I recognize that there was 
not enough of a consensus or enough of an interest among others during 
the review to have that happen now.

Among the issue brought forth by others my personal view for possibly 
improving Synapse to where it might be more acceptable to reviewers and 
might draw more people's interest as a possibly Boost library in the 
future pending another review, lies mainly in these numbered issues 
above: 2), 4), 5), 7), 8), 12), 15). I also feel having the 
documentation discuss in more detail the major concepts of the library, 
as a bridge between the Tutorial and the Synopsis, would be very helpful 
for interesting programmers In Synapse. Of course other people's views 
may vary greatly, and further discussion of Synapse on the Boost 
developers mailing list or the Boost users mailing list is, I am sure, 
welcome to the author of Synapse Emil Dotchevski.