Re: [boost] Review Request: future library (Gaskill version)

From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-04-13 20:56:24

Hello Gaskill,

From: "Braddock Gaskill" <braddock_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, April 14, 2008 12:55 AM
Subject: Re: [boost] Review Request: future library (Gaskill version)

<snip>

>> 2. What is the motivation for allowing more than one callback? This turns
>> the promise into a signal.
>
> Hehe, I go back and forth on one or many callbacks every time I revisit 
> the
> design - last time being last week.
>
> My justification is that add_callback() is really needed for authors of
> other frameworks to hook into things (see prior post on guards and
> operators).  My fear with only one callback is that, for example,
> ASIO adds future support, uses add_the_callback internally, and later a
> user of ASIO uses add_the_callback for his own purposes and breaks
> ASIO.
>
> I have considered making add_callback a friend function in a separate
> future_ext.hpp header just to distance it from standard future<> usage. 
> It
> is really only necessary to make the library extensible.

I use to put these kind of interfaces in a backdoor class which is a friend 
class .
This pattern was already used by the thread class in order to separate the 
safe interface(scoped_lock) and the unsafe one(lock/unlock), but was this 
backdoor was on a detail namespace and not in the public interface). The new 
thread library do not contains nymore this indirection.

The user of the library is not aware of this interface, but the author of 
other library will use this backdoor class knowing that the door it opens is 
a little bit more risky or unsafe and need a careful usage.

  template<typename R> class future
  {
     // ...
   private:
       friend template <typename R> class future_backdoor;
       callback_reference add_callback(const boost::function<void (void)> 
&f);
       void remove_callback(callback_reference &ref);
    }

// future_backdoor.hpp

 // ...

  template<typename R> class future_backdoor {
    future<R>& fut_;
  public:
        future_backdoor(future<R>& fut): fut_(fut){}
        callback_reference add_callback(const boost::function<void (void)> 
&f) {return fut_.add_callback(f)}
        void remove_callback(callback_reference &ref) {return 
fut_.remove_callback(ref)}
  }

The aware user could use this as follows:

    future<T> fut;
    //...
    future_backdoor<T> bd_fut(fut);
    bd_fut.add_callback(f);

or directly

    future_backdoor<T>(fut).add_callback(f);

future_backdoor behaves like unsafe cast, a little bit as for example 
const_cast.

What do you think?

_____________________
Vicente Juan Botet Escriba

> Braddock Gaskill
>
> _______________________________________________
> Unsubscribe & other changes: 
> http://lists.boost.org/mailman/listinfo.cgi/boost
>