Re: [boost] On bind::operator==, again

From: Brian McNamara (lorgon_at_[hidden])
Date: 2004-03-10 11:27:54

On Wed, Mar 10, 2004 at 12:08:30AM -0500, Douglas Gregor wrote:
> The problem is that there are a whole lot of use cases for equality of 
> function objects, and people really want them. The especially want
> 
>   delegate<void()> f; 
>   f += some_function_object; // connect
>   f -= some_function_object; // disconnect

I don't see why people can't cope with

   delegate<void()> f; 
   handle h = f.connect( some_function_object ); 
   ...
   f.disconnect( h );

instead.  Indeed, it seems to me that it might be cheaper to hold onto
the handle in some cases rather than the function object.  (A handle
could presumably be an int, whereas a function object may be many words
of data or maybe even require heap storage.)  But admittedly, I don't
typically work in these domains to know how people _actually_ use (or
want to use) these things.

Maybe the best compromise is to define a new entity for "function
equality".  Define a function (result_of-capable functor, really) like

   boost::function_equal( f, g )

which has this behavior:

 - if f and g are both function pointers, use operator==, else

 - if one or both are user-defined types, call f.function_equal(g) 
   (or g.function_equal(f)) if it exists, else

 - return false (or fail to compile, whichever people decide is best)

Then lambda expressions (et al.) can define their own notion of
function equality as they see fit, and it wouldn't conflict with the
existing meaning of operator== in lambda expressions, and libraries
(like signals) could choose to use boost::function_equal as a default
predicate if they want (in any case, the existence of function_equal
makes it easy to 'swap policies' with any algorithms that takes an
equality predicate as an optional extra parameter), and you could then
make

   delegate<void()> f; 
   f += some_function_object; // connect
   f -= some_function_object; // disconnect

work if people are really clamoring for it.

-- 
-Brian McNamara (lorgon_at_[hidden])