Message du 29/03/11 02:29 De : "Frédéric Bron" A : boost@lists.boost.org Copie à : Objet : Re: [boost] [Boost-users] [Review] Type Traits Extension by Frederic Bron - Review summary and decision
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.
Hi, I like can_can_operator_XXXX. Have you considered can_call_XXXX_operator? BTW, I don't see in the review result any constraint on the names for XXXX. I'm designing Boost.Opaque that provides some meta-function to forward the operators from the opaque class to the underlying type such as using_XXXX, hiding_XXXX and I would want to use the same as in your library. Please, could you give the list of XXXX that will be provided by the library? Thanks, Vicente