From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2004-03-01 02:20:29
> 2. Naming.
>
> A) Many of the public types and functions have obscure names. (There
> are also problems with the internal names, which I'll discuss under
> 'implementation'.) I'm willing to accept using strange names if they
> are standard names from FP; however many of the FC++-specific names
> are needlessly obscure.
>
> For example, the templates c_fun_type, fun_type and the
> smart_functoidn family are all helper templates designed to add
> functionality to a derived class, along the lines of
> std::unary_function. But the names give no indication what they are
> supposed to do. I still have no idea what the 'c' stands for in
> c_fun_type. (I'll suggest in (5) below how to eliminate fun_type and
> smart_functoidn entirely, and replace c_fun_type with 'adaptable'; I'm
> just using these as examples.)
>
> 'fun' should defintely be 'functoid'. 'full' is almost meaningless;
> I'd suggest other names, but I think full should be eliminated (see
> (5)).
I would like to second above concerns, since I forgot to mentioned this in
my review. In addition I believe we should strive to keep new names clear
and follow existing naming in STL.
For example, why ptr_to_fun named with addition _to_, while usual STL
counterpart is named ptr_fun? And secondly I believe the fact that this or
that function named some way in Haskell should not be driving force in
naming of our functors. For example I found name 'take' completely
misleading (I prefer first_n). Also functor map should probable be named
transform since it's the name for existent STL counterpart e.t.c.
Gennadiy