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.
Dear All, While my work has existed in several iterations over the last 12 years, this was the first time that it underwent a public formal review; even better, from C++ experts and Boost authors. As a result, it will become a better library. Thank you Joaquin M López Muñoz, Christian Mazakas, Ruben Perez, Yannick Le Goc, Klemens Morgenstern and Andrzej Krzemienski, for putting in the effort and time to write a full review. I would like to extend special thanks to Joaquin for convincing me to submit my library; to Professor Jose Daniel Garcia Sanchez for organizing the "using std::cpp" conference in Madrid, and introducing me to Joaquin; and to Дмитрий Архипов for managing the review. I also received valuable feedback besides full reviews. In particular, Steven Watanabe's input was comprehensive and stimulating. You will all be credited in the documentation, unless you decide to opt out (no reasons asked). I am implementing many of the suggestions, and all the conditions for acceptance. I am tracking them as issues in the repository (https://github.com/jll63/Boost.OpenMethod/issues). If you feel that I have overlooked a remark or suggestion, please open a new issue or contact me. If you want to join as a collaborator on github, you are welcome, just drop me a line. Jean-Louis Leroy On Wed, May 28, 2025 at 1:58 PM Дмитрий Архипов via Boost <boost@lists.boost.org> wrote:
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.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (2)
-
Jean-Louis Leroy -
Дмитрий Архипов