$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] [Boost-users] [Review] Type Traits Extension by Frederic Bron - Review summary and decision
From: Frédéric Bron (frederic.bron_at_[hidden])
Date: 2011-03-28 20:26:33
> Is there any problem related to using a short prefix like "is_"?
I have nothing against "is_" but what follows must be descriptive
enough, "is_xxxx" is too short.
I do not like to add "able" to all operators because it looks strange
for some of them (needs to add "_comparable" for <, >,...; "orable",
"andable", "xorable" are very strange...).
"has_xxxx" looks too short to me and the review reveiled that
"has_operator_xxxx" or "has_xxxx" alone was confusing because it is
the wrong meaning: we are not testing if the types have the operator
(as member) but if that operator can be applied.
However, I like the new proposal from Stewart (thank you)
"can_call_xxxx" which could also be "can_apply_". I like it because:
- it means what it checks,
- they will all be sorted alphabetically; what happens when I want to
use such a trait? I remember easily the prefix and go straight ahead
to the alphabetical list to get the end. Not so easy with a suffix.
Now the question is do we need "_operator" in the name which seems
logical to me: "can_call/apply_operator_xxxx". But it is quite long.
Some propose just "_op" -> "can_call/apply_op_xxxx".
This is not something that will be written very often when used so
that maybe a longer name is better because then when you read it again
months later, you understand it immediately.
Kind regards for all comments received,
Frédéric