Subject: [boost] Synapse library review result
From: Edward Diener (eldiener_at_[hidden])
Date: 2016-12-14 16:17:00
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
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.
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
15) More specific information on which compilers should work with Synapse.
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk