[type_erasure] Review report -- ACCEPTED
Hello all, Steven Watanabe's library Boost.TypeErasure is ACCEPTED into Boost. SUMMARY The library was reviewed from July 18 to August 3, 2012. There were 11 votes to accept the library and 2 votes to accept the library under the condition of some modifications (at the end, these 2 votes were essentially considered as "no" because there was no agreement on implementing all the required modifications). It was noted how the library offers non-intrusive and powerful programming techniques that can be used in place of usual Object Oriented (pure) virtual function interfaces (and with support for some from of virtual "template" functions). The library can also be seen as a generalization of existing Boost libraries like Any, Function, and AnyIterator. The library is accepted "as is", however most reviewers suggested to: 1) Dramatically ease the learning curve of the documentation by providing a motivation section, step-by-step tutorial(s) to introduce the basic features of the library, advanced topics section(s) to introduced the additional features, an example section with non-trivial use cases for the library, and additional examples to the reference section. 2) Support down-casting. While these changes are not a condition for the library acceptance, it would be best if they were made part of the very first release of the library. A few reviewers found the name Type Erasure confusing, however others did not. Alternative name were: Staged Typing, Deferred Typing, Type Interface, Interface, Static Interface, Value Interface, Structural Typing, Duck Typing, and Run-Time Concepts. There was some discussion on the meaning of Type Erasure in Java and on its definition on wiki (these should probably be both referenced in the documentation). The current library name is considered acceptable and the final decision on the library name is left entirely up to Steven. DETAILS "Yes" reviews: [1] http://lists.boost.org/Archives/boost/2012/07/195288.php [2] http://lists.boost.org/Archives/boost/2012/07/195297.php [3] http://lists.boost.org/Archives/boost/2012/07/195299.php [4] http://lists.boost.org/Archives/boost/2012/07/195308.php [5] http://lists.boost.org/Archives/boost/2012/07/195323.php [6] http://www.mentby.com/hossein-haeri/boost-typeerasure-review-ends-today-july... [7] http://lists.boost.org/Archives/boost/2012/07/195327.php [8] http://lists.boost.org/Archives/boost/2012/07/195329.php [9] http://lists.boost.org/Archives/boost/2012/07/195334.php [10] http://lists.boost.org/Archives/boost/2012/07/195364.php [11] http://lists.boost.org/Archives/boost/2012/08/195420.php "Conditional-yes" reviews (essentially considered as "no"): [12] http://lists.boost.org/Archives/boost/2012/08/195455.php [13] http://lists.boost.org/Archives/boost/2012/08/195561.php Notable comments and discussions (not reviews): (1) http://lists.boost.org/Archives/boost/2012/07/195162.php (2) http://lists.boost.org/Archives/boost/2012/07/195130.php (3) http://lists.boost.org/Archives/boost/2012/07/195149.php (4) http://lists.boost.org/Archives/boost/2012/07/195167.php (5) http://lists.boost.org/Archives/boost/2012/07/195199.php (6) http://lists.boost.org/Archives/boost/2012/07/195200.php (7) http://lists.boost.org/Archives/boost/2012/07/195232.php (8) http://lists.boost.org/Archives/boost/2012/07/195234.php (9) http://lists.boost.org/Archives/boost/2012/07/195408.php (10) http://permalink.gmane.org/gmane.comp.lib.boost.user/75081 (11) http://lists.boost.org/Archives/boost/2012/08/195590.php (12) http://lists.boost.org/Archives/boost/2012/08/195663.php (13) http://lists.boost.org/Archives/boost/2012/07/195342.php (14) http://lists.boost.org/Archives/boost/2012/08/195543.php Note that Steven might have already implemented some of the changes listed below. Features: * Support down-casting. See [1], [10], and (4). * Add macros for defining concepts. These macros could be added in later revisions (they just provide a different syntax, no additional functionality). ** From [10]: BOOST_CREATE_CONCEPT(container_concept, typename T, (void (push_back, T), void (size)) ) ** From Steven: BOOST_TYPE_ERASURE_MEMBERS((push_back)(size)...) template<class V, class T = _self> struct container_concept : mpl::vector< has_push_back<void(const V&), T>, has_size<std::size_t(), const T>, ...> {}; * Add empty() to check if any holds a value or not. See [3] and [11]. * Add a built-in concept for unary plus +x (just pick a name for it). See (11). Implementation: * Can assertion enforce that same bindings are required for the placeholders? See [13] and (3). * Add assertion to check that in functions with multiple arguments the underlining any types must match. See (7). * Add in-code comments to the implementation (at least to normalize.hpp). See [8] and [13]. * Can static assertions be used to improve error messages (see [8])? Concept mismatch spew errors with internal implementation details, see [10]. * Fix bugs: ** http://lists.boost.org/Archives/boost/2012/07/195367.php ** http://lists.boost.org/Archives/boost/2012/07/195396.php ** http://lists.boost.org/Archives/boost/2012/08/195662.php Documentation: * A few typos listed in [9]. * A draft on a proposed way to restructure the docs was offered in [8]. * Sean Parent's BoostCon 2012 "Value Semantics" could be used to write a motivation section. See [9]. * Offer a comparison with usual OO (pure) virtual function interfaces. See [1], [7], [8], and [9]. * Make sure all important elements document in the reference section are also documented in a tutorial section (e.g., how the any constructor binds placeholders, conversions, BOOST_TYPE_ERASURE_MEMBER, concept_of, etc). See (1), (4), (6), and [1]. * Clarify that references can be assigned but they cannot be rebound to a different object. See (2). * Clarify the rationale for using _a, _b, ... instead of _1, _2, ... as soon as _a, _b, ... are first used (most users miss the "named vs. positional parameter" rationale from the design decision section and _1, _2, ... are such common constructs that many users will naturally question the _a, _b, ... choice). See (5). * Add an example section with non-trivial use cases of the library. Consider to add the following examples: ** How to implement visitation, see (8). ** Model view controller, see [1]. ** Run-time expression system (adding Concept = void specialization), see [3]. ** Multi-function, see [4]. ** Printing, see (11) (note that Steven needed to answer too many questions for Paul to be able to program this, ideally the docs would have been clear enough for Paul to program this example without Steven's help). ** Reference related work Adobe::Poly, see (13). * Document all built-in concepts (possibly with a usage example for each) and indicate which ones can be specialized. See [5], and [9]. * Add an example at the bottom of each reference page. See [11]. * Document that any(any<Concpet2, T2>, binding<Concept>) allows to convert the vtable once and re-use it for all anys reducing run-time cost. See [12]. * Consider a number of docs improvements as suggested in [13]. * Document the undefined behaviour pointed out in (12). * Document limitations that some algorithms might encounter if they need to access references and provide rationale of why references cannot be handled differently (i.e., constructor flag and/or overhead of managing vtable in dispatcher layer). See [12], and (14). Many thanks to everyone that participated in the review!! I believe Boost users will find this library useful. The review manager, --Lorenzo On Sat, Aug 4, 2012 at 12:32 PM, Lorenzo Caminiti <lorcaminiti@gmail.com> wrote:
Lorenzo Caminiti wrote:
Steven Watanabe's library Boost.TypeErasure is ACCEPTED into Boost.
Congratulations Steven! Thank you, Lorenzo, for a quick, clear, and complete review report. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com ________________________________ IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
participants (3)
-
Lorenzo Caminiti -
Paul A. Bristow -
Stewart, Robert