Re: [boost] [futures] boost::futures - convertible types

From: Braddock Gaskill (braddock_at_[hidden])
Date: 2007-03-16 13:32:05

On Fri, 16 Mar 2007 12:11:38 -0400, Frank Mori Hess wrote:

> On Friday 16 March 2007 11:05 am, Braddock Gaskill wrote:
>> One thing I did not do (yet) was add a generic conversion function
> 
> Here's an example extracting at(1) from a future vector:
> 
> poet::future<std::vector<double> > myVec;
> poet::future<double> myVecElement(myVec, boost::bind<const 
> double&>(&std::vector<double>::at, _1, 1));

Hrm, this has profound implications.  I don't know if they are good or bad, but
they go beyond my current understanding of the future idiom.

This allows you to not just embed conversion functions, but ANY function, in
the guise of a future<T>.

future<double> func1(const future<double> &a);
future<double> func2(const future<double> &a);
future<double> func3(const future<double> &a);

promise<double> p;
future<double> f0(p);
future<double> f1(f0, func1); // f1.get() equiv to func1(f0)
future<double> f2(f1, func2); // f2.get() equiv to func2(func1(f0))

f2.get(); // Does caller realize this is actually a call to func2(func1(f0))??

future<double> f3 = std::fork(bind(&func3, f2));
// Did the author of func3() realize his call to a.get() might do _anything_?

Of course the assignable type conversions already let the cat out of the bag,
not just the generic conversion functions.  In fact, my add_callback() hook
opens a similar bag of worms for the promise::set() call.  I really only want
add_callback as a hook to allow independent event notification models and
composition to be developed on top, not for end user use.

So, good, bad, or awesome? ;)