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

Subject: Re: [boost] [Review] Type Traits Extension by Frederic Bron - Review summary and decision
From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2011-04-28 12:54:26

2011/4/28 Stewart, Robert <Robert.Stewart_at_[hidden]>:
> Joachim Faulhaber wrote:
>>
>> I chose "has_" for the same reason: Consistency within boost,
>> because the type traits library uses has_ in similar instances.
>> The argument, that this is an imprecise naming because for free
>> standing operators ownership can not be determined is
>> unimportant because we may conceive the complete type signature
>> as the type that "owns" the operator:
>>
>> A x B -> B  has_plus
>
> Thinking of A and B as a universe that may or may not include
> a particular operator, whether through a member function or not,
> is a reasonable way to interpret things.  On that basis, I now find
> "has_" acceptable.

the beauty of generic designs based on concepts is, that it gently
dissolves object oriented views of membership anyway. So we can think
of a triple of types

(A1, A2, R)

that "has" an implementation for an operator @
which means that it is applicable, can be called on or supports those
type arguments.

has_ reads well under this "modern" interpretation. We can prefer it
for consistency sake concerning other uses of has_ in Boost.TypeTraits
and because

> it has simplicity and brevity;
as Jeff wrote

Joachim

-- 
Interval Container Library [Boost.Icl]
http://www.joachim-faulhaber.de