Dave Abrahams said: > On Thursday, February 06, 2003 12:33 PM [GMT+1=CET], > William E. Kempf <[EMAIL PROTECTED]> wrote: > >> Dave Abrahams said: >> >> > > Hmm... that would be >> > > an interesting alternative implementation. I'm not sure it's as >> "obvious" as the syntax I suggested >> > >> > Sorry, IMO there's nothing "obvious" about your syntax. It looks >> cumbersome and low-level to me. Let me suggest some other syntaxes >> for async_result, though: >> > >> > async_call<double> later(foo, a, b, c) >> > >> > or, if you don't want to duplicate the multi-arg treatment of >> bind(), just: >> > >> > async_call<double> later(bind(foo, a, b, c)); >> > ... >> > ... >> > double d = later(); // call it to get the result out. >> >> The two things that come to mind for me with this suggestion are: >> >> 1) You've explicitly tied the result into the call. I chose the other >> design because the result is just that, only a result. > > Hm? How is the result not a result in my case?
I didn't say it wasn't a result, I said that it wasn't "only" a result. In your case it's also the call. >> An asynchronous call can be bound to this result more than once. > > ...and if it can't be default-constructed? That's what boost::optional<> is for ;). >> 2) You're still hiding the thread creation. > > Absolutely. High-level vs. low-level. But I think too high-level. I say this, because it ties you solely to thread creation for asynchronous calls. >> This is a mistake to me for >> two reasons. First, it's not as obvious that a thread is being >> created here (though the new names help a lot). > > Unimportant, IMO. Who cares how an async_call is implemented under the > covers? I care, because of what comes next ;). >> Second, and this is more >> important, you've bound this concept to boost::thread explicitly. >> With the fully seperated concerns of my proposal, async_result can be >> used with other asynchronous call mechanisms, such as the coming >> boost::thread_pool. >> >> asyc_result<double> res1, res2; >> thread_pool pool; >> pool.dispatch(bind(res1.call(foo), a, b, c)); >> pool.dispatch(bind(res2.call(foo), d, e, f)); >> d = res1.value() + res2.value(); > > This one is important. However, there are other ways to deal with this. > An async_call object could take an optional thread-creation parameter, > for example. It's not "thread-creation" in this case. You don't create threads when you use a thread_pool. And there's other examples as well, such as RPC mechanisms. And personally, I find passing such a "creation parameter" to be turning the design inside out. It might make things a little simpler for the default case, but it complicates usage for all the other cases. With the design I presented every usage is treated the same. More importantly, if you really don't like the syntax of my design, it at least allows you to *trivially* implement your design. Sometimes there's something to be said for being "lower level". >> > That's what we mean by the terms "high-level" and "encapsulation" >> ;-) >> >> Yes, but encapsulation shouldn't hide the implementation to the point >> that users aren't aware of what the operations actually are. ;) > > I don't think I agree with you, if you mean that the implementation > should be apparent from looking at the usage. Implementation details > that must be revealed should be shown in the documentation. I was referring to the fact that you have no idea if the "async call" is being done via a thread, a thread_pool, an RPC mechanism, a simple message queue, etc. Sometimes you don't care, but often you do. -- William E. Kempf [EMAIL PROTECTED] _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
