2011/3/29 Frédéric Bron <frederic.bron@m4x.org>:
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...).
is_xxxxable, will lead to some of those difficulties. I recognized that when I summarized the wiki table for a Most Unifying Proposal. I think a simple schema prefix_xxxx or xxxx_suffix is the best solution.
"has_xxxx" looks too short to me
not 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.
Unfortunately I started this discussion. Meanwhile has_xxxx is one of my favorites.
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,
is_callable_xxxx or xxxx_is_callable are good names as well. I'd prefer xxxx_is_callable, because it seems closest to natural language.
- they will all be sorted alphabetically;
with and without prefix ...
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.
To me such considerations are of almost no significance. Sequences of lists and synoptic tables are always subject to the context of usage. For instance many times people are searching operators under the aspect of precedences. Would we start prefixing the operator names with precedence_i_has_operaotor_xxxx only to support ease of perception for this particular aspect? The basic naming of entities that are so fundamental to a language like operators should IMO be completely free from considerations like this.
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.
yes
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.
op_ is an abbreviation which is generally discouraged in std/boost naming. operator_ is a prefix that is redundant, because it is clear from the context. Best, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de