[boost] Re: compose names

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
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 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.

--Beman

------------------------------------------------------------------------

eGroups.com home: http://www.egroups.com/group/boost
http://www.egroups.com - Simplifying group communications