On Fri, 16 Mar 2007 13:37:33 -0400, Frank Mori Hess wrote:
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.
It could be implemented as a free function instead of a constructor, to give it a little conceptual separation from the future class proper.
Yeah, maybe I'll make a seperate "future_friends.hpp" with free functions for adding a future callback or a general conversion function. That way people can sort of hook into the implementation if they are making a broader framework and know what they are doing (like libpoet vector adaptors or compositions), but with a clear "do not abuse this at home" banner. I can see many interesting uses of these future adaptor functions, but at the end of the day an object that you call to get a return value and any arbitrary behavior is called a "functor" not a "future". I've previously developed a sort of heavyweight future concept that I called a "place". I'm excited about discovering futures because they are MORE constrained, while my "place" concept was powerful and convenient, but always left me wondering if I'd covered every conceivable case. I'll still be using "place" where needed, but future everywhere else... -braddock