From: Andreas Huber (ah2003_at_[hidden])
Date: 2003-06-15 15:49:37
> But it seemed to
> be a successful modeling and I had to concede; why should a "niche"
> concept such as "protocols" foul the "global namespace" of a generic
> modeling language?
>> 1. Events that can carry parameters
>> 2. A call-back mechanism a la boost::function, so that an FSM that is
>> answering a request does not have to know who it is answering to.
>> boost::intrusive_ptr< Request > pRequest = new Request();
>> // set params
>> A & machine = context< A >();
>> pRequest->callback = boost::bind( &A::queue_event, machine, _1 );
>> B::instance().queue_event( pRequest );
>> So, IMO there's no need for boost::fsm to provide communication
>> protocol primitives, because their functionality is pretty
>> orthogonal to what my library does. Users would want to use what
>> they're accustomed to. Most would presumably use boost::function.
> Yes. Think with 1, 2 and putting distance between boost::fsm and comms
> you have nailed something for me. Maybe there will eventually be a
> boost::signaling (damn
> thats somewhat overused) or boost::eventing (sounds like a horse
> race) that will
> complement your current targets?
I'm not sure I understand what such a library would do (there's already
boost::signals which covers publish-subscribe pattern, which BTW could be
interesting for certain types of inter-FSM communication too). Can you
> I feel responsible for something of a detour into the subject of SDL
> and the comparison of UML with SDL.
I don't see it as a detour. It was valuable to see SDL's approach to FSMs.
It is even more valuable to see what questions might arise when people not
familiar with UML consider using boost::fsm.
> I hope that this detour has
> uncovered something of
> use for you (certainly has for me)
It definitely has. All that remains is that tiny last question ;-) above.
Thanks & Regards,