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-21 12:16:29

2011/3/21 John Maddock <boost.regex_at_[hidden]>:
>> (2.3) I'd prefer has_xxx over has_operator_xxx because I think that
>> operator names xxx can stand for themselves without an "operator_
>> reminder" prefix. The has_operator_ prefix is lengthy and introduces
>> unnecessary redundancy.
>
> Hmm, I'm not sure it is completely redundant - I prefer
> long_descriptive_names to short_cute_ones because it makes the code easier
> to understand - even though it result in a touch more typing.

There may be conflicting principles e.g. descriptiveness, ease of
perception versus conciseness, simplicity and naming decisions may
vary between them.

(2.3.1) In my view a naming style of systematic pre or postfixes may
lead to reduced readability, due to induced redundancy that clutters
code. My favorite example is the use of pre/suffix "type" both in c++
language design as well as in well known naming conventions
(std/boost). I think (1) is less readable than (2):

// "type" is used 5 times as pre or suffix (1)
typedef typename foo_type::key_type mykey_type;

// instead of (2)
type mykey = foo::key;

(2.3.2) In addition, if say 'plus' is a functor that wraps operator
'+' in the standard's <functional> header, would we want to name it

template<class T> struct functor_for_operator_plus; //?

Many aspects about a name in a program are given by its context. I
think it is an unnecessary introduction of verbosity and redundancy
often, to repeat information as part of a name that is already clear
by its context. This is what I mean when I talk about a reminder
prefix.

string x_str; // suffix str redundant. Clear from the context.

The context for std::plus is:
* There is a set of very important function symbols called operators.
* For those core symbols there are uniformly usable functors that wrap
the operators.
* From this it is clear that all those functor classes are
functor_for_operator_xxx

So functor_for_operator_ does not have to repeated as component of all
those names.

Joachim

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