Subject: Re: [boost] [Review] Type Traits Extension by Frederic Bron - Review summary and decision
From: Barend Gehrels (barend_at_[hidden])
Date: 2011-04-21 15:09:50
> Also, while we're on the topic of what *I* prefer: I still prefer
> "has_xxx". To me, it has an implicit association (to me, anyway) to the
> names of trait predicates; it has simplicity and brevity; and it has
> existing use in Boost.TypeTraits. I can sympathize with arguments against
> "has_xxx" / for "can_call_xxx", I just never thought they were convincing
> enough :/
> The decision is ultimately Mr. Bron's, though, and I'm sure he's doing his
> best to try to please everyone :)
There are two things: the names and the prefix. And they are related.
About the prefix: I don't like can_call_. It is novel as Joachim says,
and AFAIK not widely used, and looking a bit awkward (in my opinion). In
such cases I normally use "supports", so: supports_addition,
supports_equal, supports_not. It is not shorter (neither longer) but
reads more smoothly. Next step: inserting the "operator_ " is even more
clear. So supports_operator_not is more convenient: longer, but more
clear. Next step: then "has_" is more convenient, because complying to
existing practice. So: "has_operator_not". Perfect.
But "has_operator_addition" is not perfect, is awkard. This shows the
problem, the prefix and the name are related: it should then be
has_operator_plus... It is not the "operator_addition" it supports, it
is the "operator_plus" it supports (doing an addition).
About the names (and the names only), I agree with Joachim, conform to
existing practice, don't invent the wheel again. Proto has all of the
presented list, but using other terms. So why type types extensions
would present another compilation? Why should it be
proto::plus and can_call_addition?
proto::equal_to and can_call_equal?
proto::shift_left and can_call_left_shift
OK, it is not consistent among Boost libraries (which is bad), but then
take the library having the complete list (which is probably Proto).
So I prefer what (if I'm right) has been proposed before:
proto::plus and has_operator_plus
proto::equal_to and has_operator_equal_to
proto::shift_left and has_operator_shift_left
all exactly like proto, but having the "has_operator_" prefix. I cannot
remember what was the objection to has_, but then supports_ would be the
alternative of my choice.
The only exception would be, for logical reasons, and_ and or_ and not_, so
proto::and_ and has_operator_and
proto::or_ and has_operator_or
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk