Re: [boost] New New Callbacks Uploaded

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-11-23 14:22:45

In message <200011230812.AAA19587_at_[hidden]>, Jesse Jones
<jesjones_at_[hidden]> writes
>>I presume that the default would have to err on the side of safety.
>>Although is no need to copy member or non-member function wrappers,
>>there is an issue over the amount of specialisation involved to meet the
>>expectations, eg pretty much all function object types in the standard
>>and I guess many parts of the Lambda library. How much coupling do we
>>want?
>
>We could rig it so that the Lambda library didn't couple at all to the 
>callback class. All we have to do is stick some sort of thread trait 
>somewhere and let Lambda specialize it.

This is not quite what I meant. Or rather, it is what I meant. I had no
intention of coupling the Lambda library to the callback class. I was
talking about the problem of coupling the callback library to the Lambda
library. This is the configuration and source bloat I would be worried
about, and why I think this may not be the path to follow.

>>>>(3) Not implement reference in the function_ptr at all.
[...]
>>        shared_ptr< function_ptr<void> > s(new_function_ptr(f));
>>        ...
>>        s();
>
>Sure, but if 99% of the time I'm wrapping function_ptr up in a shared_ptr 
>I'd begin to wonder why I couldn't just copy the damned callback object.

I've not found the need (where "want" and "need" are not the same idea
;->) to use anything but cloning, so I would be suspicious of figures
like 99%... or indeed 9.9%. This is not to say that the need does not
arise, just that I would not wish to bend the class out of shape when we
already have a clear and acceptable solution to that situation above.

If someone can demonstrate the need _and_ that the need is common (and
the distinction between "want" and "need" is again important), then it
may be worth pursuing an internal solution. As it stands, the more
orthogonal solution suits me fine, and keeps things simpler by
eliminating the issues.

Kevlin
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  Curbralan Limited               mobile: [phone]
  mailto:kevlin_at_[hidden]     fax:    [phone]
  http://www.curbralan.com
____________________________________________________________