Re: [boost] [Review] Type Traits Extension ending tomorrow

Subject: Re: [boost] [Review] Type Traits Extension ending tomorrow
From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2011-03-21 06:43:21

2011/3/18 Joachim Faulhaber <afojgo_at_[hidden]>
>
> 2011/3/17 Joel Falcou <joel.falcou_at_[hidden]>:
> > 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