Boost logo

Boost :

From: Beman Dawes (beman_at_[hidden])
Date: 1999-06-10 08:26:02

At 11:40 PM 6/9/99 +0100, Sean Corfield wrote:

>I'm not entirely happy with the names chosen for the various compose
>functions in Nico's library. Having a two digit number is cryptic at
>When I presented compose variants in Santa Cruz last year, I gave
>names to the variants where I couldn't overload the basic 'compose'
>variants. Was this considered?

Nico originally used the names:

Functionality Name SGI STL's Name
f(g(value)) compose compose1
f(g(value),h(value)) inject_compose compose2
f(g(value1),h(value2)) distr_compose
f(g(value1,value2)) binary_compose

I think these were the names you suggested. Then I asked Matt
Austern for his view, because HP/SGI already had some compose
functions. Here is Matt's comment:

>Unfortunately, while I don't like Nico's naming scheme, I still
>have a better one to propose. I'll try once more to come up with
>better. My reasons for not liking it:
>-- The HP and SGI STL implementations have included unary_compose
> binary_compose (with helper functions compose1 and compose2) for
> years. At this point I don't see how we could rename them. I'd
> rather come up with a naming scheme that kept those names.
>-- Nico's scheme has the virtue of being consistent, but I don't
> it's a clear as it ought to be. It's consistent because it uses
> mathematical terminology, but I don't think that the mathematics
> part of most people's common knowledge. (I've got a degree in
> and I wasn't familiar with those terms until Sean explained them
> Nico and me.)
>A few years ago I came up with names for the two missing compose
>objects; my naming scheme, if I remember it correctly, was something
>like this:
>f(g(x)) unary_compose compose1
>f(g(x), h(x)) binary_compose compose2
>f(g(x, y)) unary_compose_binary compose12
>f(g(x), h(y)) binary_compose_binary compose22
>This naming scheme is consistent (the adaptors that produce binary
>functions are elaborated with "_binary" and the ones that produce
>unary functions are unelaborated), but, as with Nico's scheme, they
>just aren't sufficiently clear. (Which is why we never included
>extra compose adaptors in our library.) I prefer my scheme to
Nico's, but
>I don't really think either one is good enough. I'm still hoping
>we can come up with a name that's descriptive and not unwieldy
>about the double negative), and I'd rather not commit to a naming
>scheme until we can find a good one.

After some more back-and-forth looking at variations, Nico revised to
the names to:

Functionality Boost Name SGI STL's Name
f(g(value)) compose11 compose1
f(g(value),h(value)) compose21 compose2
f(g(value1),h(value2)) compose22
f(g(value1,value2)) compose12
f(g()) compose10

While this naming scheme isn't perfect, it is easy to remember once
you understand that the first number is the number of functions and
the second is the number of arguments.


------------------------------------------------------------------------ home: - Simplifying group communications

Boost list run by bdawes at, gregod at, cpdaniel at, john at