[boost] Re: [Threads] Simple active object wrapper, take 2

From: Matthew Vogt (mvogt_at_[hidden])
Date: 2004-03-02 17:43:56

scott <scottw <at> qbik.com> writes:

> Yep. All straight now. I know understand your breakdown of calls
> to callbacks is very similar to that inherent in SDL. And yes, you/we/it
> are fully asynchronous.
> 
> I'm assuming you prefer this to the reactive object version? Which
> does a pretty good job of hiding the comms  Oh yeah, and doesnt
> require selection of the method to call in either the receipient
> or the client (on response), i.e. at the point of making a method
> call.
> 
> Maybe we're down to a matter of taste?

Yes, I guess it depends on whether you're familiar/comfortable with the message
passing paradigm, or whether you're more comfortable with C++ shenanigans to
obscure the messy details.

I would postulate, however, that wrapping the details to allow binding at the
call site (or message post) is slightly superior, due to the removal of the
dispatch.  Of course, this minor gain may easily be outweighed by the 
contortions required to make it work, and the reduction in the transparency
of the code...

> > I hadn't realised how integral the state machine was to your 
> > design until I 
> > read your other post.  Still, if you are doing dispatch on 
> > both message code 
> > and object state, it can be simplified to bind the message to 
> > a per-message
> > code dispatch function which then dispatches on object state.
> 
> Characterizing of reactive objects as a framework for state machines
> would be a little bit sad. I'm not sure it was your intention to say
> that so just in case others are listening, I will elaborate from
> my POV.
> 

Sorry, I read too much into the example code in the other message.  I assumed
the messaging would be an independent layer, but that the design you were
using must have the communicating objects modelled as state machines. Thanks
for clearing that up.

<snip>

> The messaging facillity has _no understanding_ of what the recipient does
> with a message. Proxies and state machines were intended to highlight
> the benefits of that design.
> 
> To summarize; the Reactive Objects that I currently consider our target
> would communicate via a similar mechansim and there would be no
> assumption that a Reactive Object was a state machine, or a proxy, or
> anything except an object that accepts messages.

Yes, that all sounds good.

> Cheers,
> Scott

Matt