2011/3/18 Joachim Faulhaber <afojgo@googlemail.com>
2011/3/17 Joel Falcou <joel.falcou@lri.fr>:
Dear All,
The fast track review of Frédéric Bron's extensions to the Type Traits Library is ending tomorrow.
... but today I won't have time. Therefore I'd like to ask for extension of the review until Monday 03-21. If a general extension is not possible I request an extension for the submission for my review.
Dear Joel, Frédéric, list, this in my review Frédéric Bron's extensions to the Type Traits library. The type_traits extensions by Frederic Bron seem to be a useful and welcome tool for meta programming purposes that is particularly handy in the context of generic library programming. I vote for ACCEPTANCE of the extension into boost. There is only on issue (1) that I consider a conditional (kind'a cosmetic though): (1) Template parameter Identifiers are lower case except for the first letter. This is official boost policy. Only BOOST_MACROS are completely upper case. So: template<class Left, class Right, class Result> instead of template<class LHS, class RHS, class RET> Abbrs. are dscrgd. ;) All other points (2-6) are proposals, ordered by my personal priorities: (2) Concise and consistent naming. (2.1) I have started a wiki page with a list of names for operators and their functors in the wiki, that tries to focus on consistency and convergence of names across the standard and boost. https://svn.boost.org/trac/boost/wiki/Guidelines/Naming/Operators It contains a few modifications of the names proposed by Frédéric. (2.2) While xxx_is_callable or is_xxxable might be slightly more precise names, I think I can also live with has_xxx. (2.3) I'd prefer has_xxx over has_operator_xxx because I think that operator names xxx can stand for themselves without an "operator_ reminder" prefix. The has_operator_ prefix is lengthy and introduces unnecessary redundancy. (3) Motivation and examples. One of the most important tasks for boost authors and boost as a whole is the communication of the motivation, purpose and usefulness of their innovations. I am repeatedly amazed how many developers find boost kind of freaked out and beyond the needs of "daily" software development. Part of the problem is that boost authors tend to take the beauty of their inventions as self-evident and do not see the need to communicate the key ideas and benefits of their work. So IMO the documentations lacks a concise and convincing motivation of why we want operator trait meta functions and some good examples that demonstrate important use cases. (4) For the include file that includes all has_operator meta functions I propose to use type_traits/has_operator.hpp instead of type_traits/operators.hpp That would be more consistent with the has_xxx.hpp file names and also more precise. I'd leave operators.hpp free for usage on -- well -- operators. (5) Since the arguments of has_xxx<T1, T2, R> are not matched exactly but in their "convertible form", there should be a chapter in the docs explaining these rules and the consequences for practical use, similar to the nice and clear explanations given on the list. (6) I'd be nicer if we had quickbook docs, but as Frédéric has pointed out he integrates into the the prevailing style of the "mother library". Still it may be nice to take the opporunity to update the whole type traits docs to quickbook style. But this is a lot of work of course and goes beyond the scope of the extension. Thanks again, Frédéric, for a smart piece of boost software. Best regards, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de