Dear Boost community, the formal review of candidate Boost.OpenMethod
has taken place between 28th of April and May 7th. I have received 6
reviews in total. Four of the reviews recommended unconditional, and 1
conditional acceptance. One reviewer recommended to reject the
library. The reviews came from:
- Joaquin M López Muñoz,
- Christian Mazakas,
- Ruben Perez,
- Yannick Le Goc,
- Klemens Morgenstern,
- Andrzej Krzemienski.
Also, several people have given insightful comments but did not
provide a review. I would like to thank all of the people who took
their time to write reviews or participate in the discussions. Your
effort was very important and valuable.
The outcome of the review is that Boost.OpenMethod is ACCEPTED with
some CONDITIONS.
1. The convenience header <boost/openmethod.hpp> should be changed to
not introduce identifiers to the global namespace. Reviewers suggested
several alternatives to that: either moving those global entities into
an alternative header, or put them into a dedicated namespace which
users could use via using namespace.
2. The library should not choose an arbitrary ambiguous overrider.
Virtually all reviewers have expressed strong dislike for this
behaviour. The default should be an error. More lax overrider
selection may be provided as an option.
3. The library's documentation should be improved in several areas:
* The concepts used by the documentation should be explained early on
and more thoroughly.
* The library should not claim to implement N2216, as it diverges from
it significantly. Instead it may remark on being inspired by it.
* Better explain potential platform-specific limitations of certain
use cases (runtime loading of shared libraries) and error conditions.
In addition, I want to discuss several criticisms that have been
expressed during the review. One is that essentially the library
doesn't solve a problem that is worth solving. That is, you never need
an open set of types combined with an open set of operations. I
believe that 10 years of library's use should mostly dispel such
concerns. I personally have also encountered such a situation in my
practice.
The second criticism is that the flexibility of the library comes with
higher chance of programmer error, as some usual safe guards go out
the window. I can attest that in "many types, many operations"
situations alternative approaches are comparably error-prone. It seems
to me that this is largely inherent to the complexity of the problem.
My advice to the author is to highlight dangerous situations, so that
potential users can better evaluate if the added flexibility is worth
it.
Thanks to Jean-Louis Leroy for submitting this library to Boost. And
thanks again to the reviewers and everyone who provided feedback, who
ultimately made this review possible.
