
Boost : 
From: Beman Dawes (beman_at_[hidden])
Date: 19990610 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
best.
>
>When I presented compose variants in Santa Cruz last year, I gave
'proper'
>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
don't
>have a better one to propose. I'll try once more to come up with
something
>better. My reasons for not liking it:
>
> The HP and SGI STL implementations have included unary_compose
and
> binary_compose (with helper functions compose1 and compose2) for
many
> years. At this point I don't see how we could rename them. I'd
far
> rather come up with a naming scheme that kept those names.
> Nico's scheme has the virtue of being consistent, but I don't
think
> 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
is
> part of most people's common knowledge. (I've got a degree in
math,
> and I wasn't familiar with those terms until Sean explained them
to
> Nico and me.)
>
>A few years ago I came up with names for the two missing compose
function
>objects; my naming scheme, if I remember it correctly, was something
>like this:
>
>OPERATION FUNCTION OBJECT HELPER FUNCTION
>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
these
>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
that
>we can come up with a name that's descriptive and not unwieldy
(sorry
>about the double negative), and I'd rather not commit to a naming
>scheme until we can find a good one.
After some more backandforth 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.
Beman

eGroups.com home: http://www.egroups.com/group/boost
http://www.egroups.com  Simplifying group communications
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk