Re: [boost] [Boost-users] [Review] Type Traits Extension by Frederic Bron - Review summary and decision

Subject: Re: [boost] [Boost-users] [Review] Type Traits Extension by Frederic Bron - Review summary and decision
From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2011-03-29 14:27:36

2011/3/29 Frédéric Bron <frederic.bron_at_[hidden]>:
>> 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