On Thu, Jun 26, 2003 at 01:36:58PM +0200, Dirk Gerrits wrote:
Brian McNamara wrote:
- Reuse: FC++ reinvents a number of Boost's libraries in its
implementation, such as smart pointers and metaprogramming
tricks. A Boost version of FC++ should reuse Boost libraries for
this.
I agree. While FC++ probably would bring in a lot of new stuff, there is
*considerable* overlap with Boost's current libraries.
On the function side there's: bind, mem_fn, compose, function,
functional, and of course lambda. And then there are smart_ptr, mpl, and
preprocessor.
Reusing will probably make the implementation a lot cleaner, potentially
more robust, and ...
I have taken a closer look at what is and is not reusable. Here's what
I've come up with:
Reusable:
smart_ptr: boost::shared_ptr and boost::intrusive_ptr seem to do
exactly the same thing as fcpp::Ref and fcpp::IRef
mpl: it looks like some things here, like if_ and find can be reused.
There may be more, too.
type_traits: boost::is_base_and_derived replaces fcpp::Inherits
concept_check: it may be possible to re-use some of the machinery
here for reporting custom error messages.
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.
- 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:
Functoids. Every functoid (like id, map, enumFrom, compose) is an
instance of a corresponding data type which begins with a capital
letter (Id, Map, EnumFrom, Compose). Being able to name the type of
any functoid is important.
Data types. Classes like List and Maybe have names starting with
capital letters.
Signature information. We use names like Arg1Type, Arg2Type,
and ResultType as typedefs for functoid signatures.
LEType computer. Lambda expressions' types are named by the LEType
computer, which uses some all-caps names like LAM, LV, CALL, etc.
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.
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 dunno if either of the examples above constitutes reason enough to
bend the rules with regards to naming conventions, but I want to ask.
--
-Brian McNamara ([EMAIL PROTECTED])
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
