Re: [boost] [Review] Type Traits Extension ending tomorrow

Subject: Re: [boost] [Review] Type Traits Extension ending tomorrow
From: Joachim Faulhaber (afojgo_at_[hidden])
Date: 2011-03-19 07:33:46

2011/3/18 Stewart, Robert <Robert.Stewart_at_[hidden]>:
> John Maddock wrote:
>>
>> >(1) has_operator_xxx seems to be imprecise and misleading.
>>
>> How so?  Personally I like the idea of a common prefix for
>> all of these.
>
> The intention is that "has_operator_xxx" be read as "expressions involving these two types can use operator xxx."  The types needn't "have" such an operator where "have" suggests membership, that the operator is a member of a type.

+1

> A common prefix doesn't have to be common for all type traits.  There are already "add_," "has_," "is_," "make_," and "remove_" common prefixes.  Note also that those beginning with "has_" refer to properties of types.  These new traits do not.
>
>> >(2) has_operator_xxx introduces a redundant prefix
>> > 'has_operator' that IMO is unnecessary
>>
>> Maybe, but it makes it explicit what you're testing, and puts
>> all the operator traits together in the alphabetical index -
>> a small point I know, but it is useful none the less!
>
> That's actually a good argument against using "has_" because you *don't* want these new traits grouped with the existing "has_" traits.

+1

>> >(3) If there are close relationships between Concepts and operator
>> >traits their names should express this relation as well.
>> >
>> >My current proposal is:
>> >
>> >plus_assign_callable or even better
>> >plus_assignable   instead of  has_operator_plus_assign
>>
>> I'd prefer is_plus_assignable if we go that route.
>
> is_add_assignable
>
> (The operation is addition followed by assignment, not plus followed by assignment.)

I think there is another naming problem lurking here ;-) which I would
call: "Inadequate levels of abstraction" applied. Unfortunately this
naming flaw is already applied to names that are part of the existing
standard and in other boost libraries so I am afraid we will have to
live with them.

The basic problem here: Operators are atomic syntactical entities. The
language allows to attach arbitrary semantics to them by implementing
some behavior for them, except for the built in types, of course. But
the names used to refer to them does not refer to their syntax but to
the most common semantics attached to them.

It would have been wiser to deliberately choose names for operators
that referred to syntax, in order to emphasize that semantics vary an
is attachable to the syntax.

  sign   semantics
+ cross  addition, set union, concatenation, ...
- dash   subtraction, set difference, deletion ...
* star   multiplication, intersection, ...
/ slash  division, factorization, ...

which is not always easy since even in natural language basic
operations and names operator signes are intermingled (+ plus sign, =
equal sign).

Joachim

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