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

From: vicente.botet (vicente.botet_at_[hidden])
Date: 2008-04-14 11:13:25

Some minor modifications to the backdoor friend declaration
----- Original Message ----- 
From: "vicente.botet" <vicente.botet_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, April 14, 2008 2:56 AM
Subject: Re: [boost] Review Request: future library (Gaskill version)

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

        typedef future_backdoor<R> backdoor;

>   private:

        friend class 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);

or
      future<T>::backdoor bd_fut(fut);

>    bd_fut.add_callback(f);
>
> or directly
>
>    future_backdoor<T>(fut).add_callback(f);

or
      future<T>::backdoor(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