
This is the result summary for the Type Traits Introspection library by Edward Diener. The review have been on going from July 1st to july 17th and had generated a large amount of very interesting design discussion. The library received 5 Positive reviews and a few positive comments next to that. **The verdict is that, the TTI Library is ACCEPTED into Boost.** However, a few comments and concerns have been raised but are rather simple changes to perform and I am sure Edward will take these comments into account before releasing the library. Such comments include: * The main comment is the fact that Boost.TTI force the definitions of its meta-functions into the boost::tti. Concerns have been raised and requests made that the macro don't specify any namespace and let users bring the generated meta-functions in the namespace of their own liking. * The number of macros handling various corner cases has been raised as potentially too high. Effort to streamline the macro based interface has been requested. * Support for more compiler is needed. Some issues on ICC has been raised but are currently being looked upon (or fixed). * Naming scheme of the macro and of the generated meta-functions have to be refined to be 1/ more clear 2/ avoid some non-standard name starting with __ * Some more detailed and entry-level examples may be beneficial to the library * Pre-made macro for classical typedef like value_type or other std components has been proposed Thanks to all the participants and to Edward for this review.

On 8/2/2011 9:06 AM, Joel falcou wrote:
This is the result summary for the Type Traits Introspection library by Edward Diener.
The review have been on going from July 1st to july 17th and had generated a large amount of very interesting design discussion. The library received 5 Positive reviews and a few positive comments next to that.
**The verdict is that, the TTI Library is ACCEPTED into Boost.**
However, a few comments and concerns have been raised but are rather simple changes to perform and I am sure Edward will take these comments into account before releasing the library.
Such comments include:
* The main comment is the fact that Boost.TTI force the definitions of its meta-functions into the boost::tti. Concerns have been raised and requests made that the macro don't specify any namespace and let users bring the generated meta-functions in the namespace of their own liking.
* The number of macros handling various corner cases has been raised as potentially too high. Effort to streamline the macro based interface has been requested.
* Support for more compiler is needed. Some issues on ICC has been raised but are currently being looked upon (or fixed).
* Naming scheme of the macro and of the generated meta-functions have to be refined to be 1/ more clear 2/ avoid some non-standard name starting with __
* Some more detailed and entry-level examples may be beneficial to the library
* Pre-made macro for classical typedef like value_type or other std components has been proposed
Thanks to all the participants and to Edward for this review.+
I would like to thank Joel Falcou for being the review manager for my TTI library, Ronald Garcia for arranging the review according to the review schedule and a host of people for reviewing my library including John Maddock, Lorenzo Caminiti, Gordon Woodhull, Gregory Crosswhite, Noah Roberts, and Jeffrey Hellrung. Also thanks to all who made comments or suggestions about TTI. While designing software is for me the work of a single individual, implementation technique suggestions are always welcome. My schedule of things to do in the library, in the order in which I will work on them are: 1) Remove the metafunctions generated by the macros from any namespace. 2) Cut down on the number of macros by combining some similar macros into a single macro and dropping unnecessary macros, including the GEN macros and the MTFC macros. 3) Drop the nullary metafunctions, which are functionally redundant, whose syntactic benefits in the eye of this developer just ending up confusing and complicating the basic functionality for almost all reviewers and commenters. 4) Update the documentation to present a slower process of explaining the functionality of each metafunction, with tutorial, examples, and sample applications for using the metafunctions. Add in also a careful explanation about naming the metafunctions and/or injecting them into one's own namespace to avoid ODR. 5) Correct any mistakes in the documentation pointed out to me by others. 6) Add the ability when introspecting a type to secondarily check for other things besides the type's typedef equivalent to another type. 7) Look at the possibility of intrrospecting elements which are protected or private. Comment in the documentation about SFINAE and extended SFINAE issues when currently introspecting a type whose match is found but whose accessibility is not public. 8) Look at testing on more compilers ( clang on Linux, Intel, Sun etc. ). 9) Supply metafunctions for basic inner elements of types in the C++ standard library. I know some other suggestions have been made and I will be carefully looking over all of them to determine if there are other things that need to be done. Edward Diener
participants (2)
-
Edward Diener
-
Joel falcou