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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk