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 06:17:43

2011/3/18 John Maddock <boost.regex_at_[hidden]>:
>> Dear All,
>>
>> The fast track review of Frédéric Bron's extensions to the Type Traits
>> Library is ending tomorrow.
>> If you plan to submit a review, please do so as soon as possible.
>
>> I am clearly *in favor* of this extension (BTW what would be the
>> precise name for it?). I had fun evaluating it and trying a few
>> experiments. Alas as a result of those and the discussion on the list,
>> I reached a point where I feel I need some more time and I'd like to
>> see some more discussion on a point that I'd like to highlight:
>>
>> Naming
>>
>> (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.

(1.1) In contrast to, say, has_nothrow_assign<T>, that informs us
about the existence of an operator or trait that belongs to the type
T,
has_operator_multiplies<T,U,R> may refer to a free standing operator,
that *is designed* not to belong to a single type in many instances.
If we take e.g.

has_operator_multiplies<line, polygon, point_set>
    // BTW multiplies is misleading here as well

which one of the types <line, polygon, point_set> "has"
operator_multiplies? The question becomes more awkward, if we consider
the universe of all the overloads that are already possible for
operator * in the context of boost now and even more so in the future.

(1.2) The name has_operator_xxx misleads to the assumption, that the
signature of an operator can be checked directly. At least naive users
(like me;) may fall into this trap.

>> (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!

on the other hand, operator names are already standardized names that
can stand for themselves such that a "reminder-prefix" "operator_" for
operator_plus_assign is not needed. In contrast, we introduce
redundancy:

has_operator_plus
has_operator_minus
has_operator_divides

In the example above over 70% of naming information is redundant ;)

>> (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.

+1
is_ is the "natural" prefix for (meta)predicates. At the same time a
good remedy for name clashes with Boost.Operator.

I am sorry if I'm bugging everyone with yet another naming debate, but
I think that naming is very important in library development in
general and in the field of language operators in particular.
Operators are at the heart of a programming language. Invariant pieces
of syntax that tend to "attract" archetypal semantics. Since we are
influencing and even creating standards in boost we should be choosing
names in the operator area very carefully.

My criteria for name selection here are roughly these:

(1) Consistency with general math and scientific knowledge
(2) Consistency with standards
  (2.1) Consistency with c++ standards
  (2.2) Consistency with boost
  (2.3) Consistency with other standards, if they exist
(3) Conciseness
  (3.1) Precise and descriptive
  (3.2) Adequate level of abstraction
  (3.3) Reduced for unnecessary redundancies
  (3.4) Relatedness to other names with similar meanings.

Regards,
Joachim

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