[mailto:boost-bounces@lists.boost.org]On Behalf Of Darryl Green Sent: Wednesday, March 03, 2004 11:38 PM
I've tended to think of the tightly/early bound, just queue a functor, and the message passsing + switch case as 2 completely independent patterns, but maybe they should be built on a common framework (at a level above the detail that they both ivolve queuing some sort of object).
Yes. I agree with your distinguishing of the two forms. There is some relief to be found in that. While I can acknowledge the existence of async messaging where the sender has type knowledge of the receiver, I also think its dangerous. Given the two approaches, most developers head down the "fake method" route. This inevitably results in receipient-type knowledge and that precludes some really cool active objects (please refer to other messages if this fails to allude to anything). Also I think its right to say that there is nothing method-based that cant be done message- based; but is the converse true? There is some more fundamental reason why message-based is right that is probably rooted in theory (sets?). There has to be good reason why protocols are so "right". Everyone appreciates the content of RFCs and telephony signaling specifications but we persist with method-based messaging. <sigh> Its an area of personal wonder.
The AO pattern doesn't require that you identify the object you want to invoke the method on in the proxy, because you send the proxy to that object, and only that object. So one could drop the "this" parameter from the proxy. That would potentially allow the proxy to be routed/forwarded in a more general reactive object model (I think this was one of Scotts requirements)? I'm not 100% sure how useful this is, but it might be nice for the class of problem where you do want concurrent execution - of as many completely independent instances of the object as is "useful". The client/master doesn't care which instance - the next available one will do nicely.
IIUC, this is a de-generate form of interaction that has been touched on previously. At least in my work it imposes an unacceptable design constraint; there needs to be some identification of the receiving active object. Most significantly (?) there could not be multiple servants per scheduler (i.e. thread).
is. Perhaps its interface can be made more generic to allow its operation to be policy based. Broadening the definition from "return value" to "message delivery notification" with the sender supplied message delivery notifier object passed the return value from the handler doesn't feel too weird to include at the low level, and shouldn't cost anything for a void return without notification. Interestingly, the option to generate a a notification that a message with a handler returning void has been processed doesn't seem like a strange feature when looked at this way (a void future is a bit odd though).
Followed everything up to the point where you start discussing "return values". On one hand you do discuss this as simply another message. OTOH you do persist with some method-based concepts. Maybe this is not significant.
This observer didn't see the state machine aspect as the exclusive use, more an important use case reflected in the design. Would that be fair to say?
Absolutely.
My questions that I've been thinking out loud about (always dangerous in public) were: What is a message? What is acceptance?
Yes, essential questions :-) Respondez du jour? A message is an object that is self-discriminating (within the world of known messages) and carries associated parameters. It is always a member of a family, i.e. a protocol. A protocol and its messages is defined independent of all active objects. Acceptance I'm not so sure of. The word carries a sense of righteousness whereas the worst that active objects seem to do is discard. Protocols may include messages along the lines of "that last message was so, like; wrong" but then that exchange would itself be defined in the protocol. Maybe messages are simply processed. Or consumed. What a wimp-out.
Sorry this was so long - am I barking up the wrong tree here or not?
Its so hard to be sure. I've got my wrong tree - you find your own :-)