Re: [boost] [msm] internal/external conflicting transitions

Subject: Re: [boost] [msm] internal/external conflicting transitions
From: Michael Caisse (boost_at_[hidden])
Date: 2009-12-07 13:26:05

Christophe Henry wrote:
>> Transitions can be either internal or external. Even for simple states.
>> An internal transition in a simple state will never execute exit or
>> entry code.
>>     
>
> I didn't find this in the standard, but I might have missed it out.
> Whatever, after a lengthy discussion with Juraj Ivancic, I came to the
> conclusion that MSM needed what we called an "execution row", which is
> pretty much your internal transitions for simple states.
>   

I'll need to search the archives for this discussion (unless it was
elsewhere). As for the standard: using the UML 2.2 Superstructure
document (it is the one I have handy), Section 15.3.15 describes
TransitionKind. There are two constraints listed: 1. source state
for "local kind" must be a composite state, 2. source state for
"external kind" must be a composite state. No constraint such as
this is made for "internal kind". Additionally the Semantics for
"internal kind" work fine with simple state and are not constrained.

>> And this is where I was unclear. A better question would be: For
>> a simple state, how do I create an internal transition?
>>     
>
> For the moment, you can't easily. The only way would be to specialize
> on_entry and on_exit on some events, but this is less than perfect, so
> this feature is quite at the top of my list.
>   

For now I'll make composite states when I need an internal transitions.

<snip>

> I don't know about that change, but I know that this depth-first
> strategy has some critics (which I failed to understand).
> Whatever, after the new type of row for simple states is added, you'll
> be able to define it wherever you want in the transition table and can
> therefore decide yourself of the priority. You will not however be
> able to do it for rows coming from composites because MSM will handle
> it alone, otherwise it'd break the exit points.
> I think it is a reasonable solution.
>
>   

I agree. The solution sounds reasonable.

Thank your for being so responsive.

michael

-- 
----------------------------------
Michael Caisse
Object Modeling Designs
www.objectmodelingdesigns.com