"Peter Dimov" <[EMAIL PROTECTED]> writes: > David Abrahams wrote: >> "Peter Dimov" <[EMAIL PROTECTED]> writes: >> >>> I am not saying that this is never useful, but syntax should target >>> the typical scenario, not corner cases. >> >> Agreed. I suppose that you'll say it doesn't target the typical >> scenario because of its confusability. I wouldn't argue. Any other >> reasons? >> >> What about: >> >> result(f) > > Unqualified? ;-)
Good question ;-) Maybe so, for the generic case. If you know you're dealing with Boost.Threads, then qualified should work. >>> It makes a lot more sense (to me) to reserve operator() for the >>> Runnable concept, since that's what Boost.Threads currently uses. >> >> And prevent any other concepts from using operator()? Surely you >> don't mean that. > > No, I meant in that particular case. Okay. > We have three concepts: Runnable, Executor (executes Runnables), and > HasResult (for lack of a better name.) The AsyncCall concept I had in mind > is both Runnable and HasResult, so it can't use operator() for both. > x.result() or result(x) are both fine for HasResult. I see that you separate the initiation of the call from its creation. I was going under the assumption that a call IS a call, i.e. verb, and it starts when you construct it. An advantage of this arrangement is that you get simple invariants: you don't need to handle the "tried to get the result before initiating the call" case. Are there disadvantages? I'll also observe that tying initiation to creation (RAII ;-)) also frees up operator() for other uses. It is of course arguable whether those other uses are good ones ;-) -- Dave Abrahams Boost Consulting www.boost-consulting.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
