Re: [boost] FSM Review Announcement

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2008-08-07 11:58:21

Chris Knight wrote:
> On Wednesday 06 August 2008 1:18:33 pm Andrey Semashev wrote:
>> Sorry, I still don't get it. You already can pass events with virtual
>> functions and process them through base classes. The main problem with
>> deferred events is that there's nobody to call process(deferred_event)
>> of the FSM. Another problem is that you generally don't know the
>> complete FSM type in states or transitions, but this issue is solvable
>> with a change in the state and transition base classes.
>>
>> Could you elaborate your point, please?
> 
> I think you basically have it. I agree that the deferred event processing
> while (events_to_process) { fsm.process_dynamic(event); } shouldn't be 
> included in boost.FSM, the process_dynamic(event_c& const) function should 
> be.
> 
> Using the TagV in the event_c class, it should be possible to provide a member 
> function in state_machine to process events given only a reference to the 
> event_c base class and that calls the appropriate process(event& const) via 
> dispatching on the integer TagV. 

I see. However, tags are not a good candidate to dispatch events on 
since different events can have same tags. I think, the event itself 
should contain enough information to be dispatched after being postponed.

BTW, you can achieve the same functionality right now if you bind the 
event to the process function of the FSM and save the call into 
boost::function.

> I'm trying to figure out whether this would be a simple feature addition or 
> there is some critical piece I am missing. 

I think, this would be an interesting feature to add in future releases. 
I won't be able to implement it before the review. State and transition 
base classes will have to be extended, in order to allow to postpone 
events. State machine and event classes will have to be modified too.