[boost] Re: Interest in FC++?

From: Dirk Gerrits (dirk_at_[hidden])
Date: 2003-06-26 16:24:55

Brian McNamara wrote:
> Non-reusable:
>    bind, mem_fn, compose, function, functional, lambda:
>       (It looks like much of compose and functional is subsumed by
>       bind/lambda anyway.)  FC++ "indirect functoids" are similar to
>       boost::function objects.  fcpp::ptr_to_fun is similar to bind 
>       and mem_fn.  fcpp::lambda is somewhat similar to boost::lambda.
>       In each of these cases, however, none of the boost stuff can be
>       reused in FC++, as FC++ uses/requires so-called "full functoids"
>       to work.  FC++ must necessarily duplicate these, owing to the
>       fundamental differences in the library architecture.

That's most unfortunate. Are you sure it's something that can't be 
worked out? There have been feature requests before. ;)

>>>- Naming conventions: FC++ uses a naming convention other than Boost's
>>>     (including systematically using capital letters in identifiers).
>>
>>From what I have been able to tell in such a short time, the 'camel 
>>hump notation' is mostly used in the implementation and only slightely 
>>so in the interface. For example, things like Fun0, Fun0Impl, ... are no 
>>problem because you want to reuse Boost's facilities for these anyway. 
>>And the functiods are already 'properly' named in lowercase. Of course, 
>>there is some work to be done here, but I don't think it would be a big 
>>problem, do you?
> 
> 
> It's much more insidious than this.  There are a number of types of
> names which use captial letters visible in the client interface to the
> FC++ library.  Here are the major categories of examples that spring to
> mind:
> 
[snipped]

I had noticed these, I had just not fully considered the implications. 
See below.

> While some of these names are ones that I have made up, and thus can be
> changed "on a whim" to lowercase versions, there are still two classes
> of naming issues which I hesitate to change:
> 
>    Haskell names.  Many functoids (like enumFromTo, takeWhile, zipWith,
>    etc.) and datatypes (like Maybe) have the exact same names and 
>    behavior as their counterparts in the Haskell programming language.  
>    I've named them this way to cater to programmers coming from a
>    Haskell background, and am hesitant to change them.

Understandable. Though I find the following more compelling.

>    Functoid types.  The obvious alternative to naming the type of a
>    functoid with a leading capital letter (e.g. "compose" has type
>    "Compose") is to add a suffix (e.g. make it so "compose" has type
>    "compose_type").  Functoid type names are used a lot, though, and I
>    am not fond of the idea of making the type names longer than the
>    names of the instances.

I see. I've been bitten by this in my personal code from time to time as 
well. My compromise has been to use the Boost naming convention for 
functions, variables, and members, and use 'camel hump notation' for 
types, exactly as you have done apparently.

> I dunno if either of the examples above constitutes reason enough to
> bend the rules with regards to naming conventions, but I want to ask.

I'm not sure what the official Boost policy is, but the regex lib uses a 
considerable amount of 'camel hump notation' as well. Perhaps you won't 
have to change that many names after all. ;)

Regards,
Dirk Gerrits