Re: [Boost-users] [statechart] Pass event data to state constructor?

Subject: Re: [Boost-users] [statechart] Pass event data to state constructor?
From: Bill Clark (bill_at_[hidden])
Date: 2009-09-03 12:30:34

That does give us a couple of options. One or the other of these would
certainly be fine for a case where relatively few events need to be handled
in this way. I think, though, that it could add significant complexity to a
large statechart where all or most reactions had to involve an indirection
through a transition action plus possibly an additional in-state reaction.
Though it would work, I think the extra mechanism would obscure the
fundamental structure of the statechart.

In our case, we have an additional option, since we have objects that live
externally to the state objects and which get attached to them as they come
and go. These external objects can offer an interface for setting/getting
the triggering event; then each transit<xyz>() call can be preceded by a
call that sets the event object, and if the event object is needed it will
be available when xyz is constructed. This has some disadvantages - we lose
type safety, of course, and we become dependent on these external objects to
handle these situations - but we have a need for these external objects
anyway, and this situation is so common in our case that at the moment it
seems preferable to the option of adding additional actions/reactions to the
statechart (which will already be fairly complex).

So, I would still lobby for the addition of
simple_state::triggering_event(), but we do have options in the meantime.

Thanks,
Bill

On Thu, Sep 3, 2009 at 1:56 AM, Andreas Huber <
ahd6974-spamboostorgtrap_at_[hidden]> wrote:

> This can be determined with the token, perhaps supplemented with queries to
>> other objects.
>>
>
> Ok, in this case one easy option would be to make the query within the
> transition action. Contrary to the entry and exit actions, a transition
> action does have type-safe access to the triggering event. If other objects
> need to be queried then these could be accessed from the transition action
> as well. The data that is gathered in the query could be put into a new
> event which is passed to simple_state::post_event. The destination state
> would then define an in_state_reaction triggered by the new event.
>
> Or, if you want to make the query after entering the destination state:
> Repost the event carrying the token in the transition action and define an
> in-state reaction triggered by the same event. The in-state reaction would
> then execute the query and store the data in the destination state.
>
>  I should have mentioned that in our system this is a general pattern, with
>> different token and data types that need to be responded to differently in
>> different states - this is why it seems that the most reliable and general
>> solution would be to pass the event data into the new state. It's true
>> that
>> this removes type safety, since I now have to dynamic_cast or equivalent
>> in
>> order to get to the actual data, but I'm not terribly worried about this
>> (or, maybe more accurately, I don't see a better alternative).
>>
>
> See above, an alternative is the "transition action posts event that
> triggers an in-state reaction"-pattern (what a name :-)). With this pattern
> type-safety is upheld, at the cost of needing to process an additional
> event, which is probably negligible is your case. Another (IMO minor)
> problem is that you might need move some of the things that you planned to
> to in the destination state entry action to the in-state reaction.
>
> HTH,
>
>
> --
> Andreas Huber
>
> When replying by private email, please remove the words spam and trap
> from the address shown in the header.
>
>
> _______________________________________________
> Boost-users mailing list
> Boost-users_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/boost-users
>