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. ;)
[snipped]- 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:
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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
