Re: [boost] [MSM] Is there any interest in C++14 Boost.MSM-eUML like library which compiles up to 60x quicker whilst being a slightly faster too?

Subject: Re: [boost] [MSM] Is there any interest in C++14 Boost.MSM-eUML like library which compiles up to 60x quicker whilst being a slightly faster too?
From: Krzysztof Jusiak (krzysztof_at_[hidden])
Date: 2016-02-16 11:44:57

On Mon, Feb 15, 2016 at 12:17 PM, Vicente J. Botet Escriba <
vicente.botet_at_[hidden]> wrote:

> Le 15/02/2016 11:08, Krzysztof Jusiak a écrit :
>
>> On Fri, Feb 12, 2016 at 6:44 PM, Vicente J. Botet Escriba <
>> vicente.botet_at_[hidden]> wrote:
>>
>> Le 12/02/2016 12:20, Krzysztof Jusiak a écrit :
>>>
>>>
>> For me it is semi clear, but I do agree with your conclusion though.
>> However, there is no info about guards being executed before src state
>> exit.
>> It might be implied by the statement that transition has to be enabled,
>> but
>> I'm not sure about it.
>>
>>
> Yes, I believe that event reception and the guard evaluation are the
> enablers of the transition.
>
>
Yea, but that would mean that guard has to be evaluated before exit of the
state or any action, so the order would be.

1. guard [to enable transition]
2. exit src state
3. actions...
4. entry dst state

When the actual state change should happen in above sequence it's not
stated in the document as well.

I would assume following order according to the spec + a bit of rationality?

1. guard [to enable transition]
2. exit src state
3. actions...
4. CHANGE THE STATE TO DST HERE?
5. entry dst state

>
>
>>> BTW. I have a question related to local transitions. Concept seems to be
>>>
>>>> nice but I don't undesrtand why exit/entry is NOT triggered only 'if the
>>>>>> main target state is a substate of the main source'.
>>>>>> Why this concept can't be more general? Wouldn't that be nice?
>>>>>>
>>>>>> s1 + e1 = s2 // exit from s1 / entry to s2
>>>>>> s1 ^ e1 = s2 // no exit from s1 / no entry to s2
>>>>>>
>>>>>>
>>>>>> A local transition will ensure that there is no exit on s1, but there
>>>>>>
>>>>>> should be an entry in s2 if s2 is not s1.
>>>>> You will need to have a nested examples to see the difference between
>>>>> an
>>>>> external and a local transition.
>>>>>
>>>>> Yea, I do get it. Cheers. Do have any example when local transitions
>>>> are
>>>> useful? I see some usage for them but I struggle really to find a really
>>>> good use case for them.
>>>>
>>>>
>>>>
>>>> Let say that you have a state S with two sub-states S1 and S2.
>>>>
>>> While in state S, if you receive the event E1 you want to go to S1, but
>>> don't want to execute the exit of state S. However you want to execute
>>> the
>>> exit of S1 or S2.
>>>
>>> S ^ E1 = S1;
>>>
>>> Think of E1 as an event that interrupts whatever you were doing on S1 or
>>> S2.
>>>
>>>
>>> Yea, yea I do get that. I was asking more about real life example. I
>> mean,
>> what use case would require such behavior, because I can't think of any,
>> but I know there are some.
>> I'm asking because I don't have any experience with local transition and
>> it
>> is hard to justify adding a new feature without a meaningful rationale.
>>
>>
>> Let say that we are on a disabled state. In this state you have
> sub-states representing the path to go to another enabled state (e.g.
> requesting a password, ...) .
> If you receive a reset event this would disable any trial to go to the
> enabled state.
> From the disabled state you could have a local transition when receiving
> this reset event and go to the sub-state disabled/idle.
> What is important is that you are always in the disabled state, so the
> disabled exit has not been executed.
>
>
Cheers, it helps a lot.

>
> Vicente
>
>
> _______________________________________________
> Unsubscribe & other changes:
> http://lists.boost.org/mailman/listinfo.cgi/boost
>