Le 06/02/2016 22:07, Krzysztof Jusiak a écrit :
On Sat, Feb 6, 2016 at 12:03 AM, Vicente J. Botet Escriba < vicente.botet@wanadoo.fr> wrote:
Le 05/02/2016 22:30, Krzysztof Jusiak a écrit :
Thanks for materials and ideas. It's a really intresesting idea with the pseudo states. I'm not sure if it is not to complex for msm-lite, but I will defo take a look. Your approach also gave me and idea to add exception handling into the transition table the way events are handled too. Not sure about such approach, but I guess, it's worth to consider too.
src + event [guard]/action = dst // guard throws runtime_error src + exception
= X // handle exception Yes, this is the idea. Anyway, I have created a ticket for it here -> http://boost-experimental.github.io/msm-lite/TODO/index.html Suggestions are more
than welcome as I'm not sure what would be the best solution here.
Can you elaborate what you mean by `inheritance of state machines`, please? Is the question related to composite/sub state machines or just whether a state machine might be inherited?
A derived state machine can refine a base state machine in different ways:
1* adding new transitions 2* refining a state by adding sub-states and transitions 3* refining the next state of a transition with a sub-state of the derived next state (or an entry point, but I believe that MSM-lite has no entry/exit points associated to an state, isn't it?)
Not yet, explicit entry/exit points are not supported yet.
4* refining the guard of a transition 5* refining the action of a transition
I'm for at least the 3 first extension mechanisms. The last two can be emulated with virtual functions. Point 3* could be not needed if the base class transitions make use of entry points.
Okay, well, msm-lite doesn't support that as a feature. However, you can achieve more or less all of mentioned things just by using C++. For example, you can extend transiton table of a state machine by joining it with another one.
auto table1 = make_transition_table(transitions...); auto table2 = make_transition_table(table1, other_transitions...);
This should respond to point 1*. 2* should need to replace the refined state in table1. Point 3 would covered if the make_transition_table function overrides the redefined transitions. It would be great if you show how the user can address these points with your library using some run-able concrete examples. Vicente