Hello Gaskill, From: "Braddock Gaskill" <braddock@braddock.com> To: <boost@lists.boost.org> 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