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-02 18:14:17

This can be determined with the token, perhaps supplemented with queries to
other objects.

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).

The idea of saving the event data somewhere worries me, since I would have
to be careful that the new state picks up the data that's really meant for
it, that there are no race conditions, that orthogonal states work correctly
in this scenario (meaning multiple event objects have to be handled this
way), etc.

On Wed, Sep 2, 2009 at 2:00 PM, Andreas Huber <
ahd6974-spamboostorgtrap_at_[hidden]> wrote:

> In the scenario I'm thinking of, we have an event which says "data is
>> available" from a data source. We don't want to put the data itself in the
>> event, because it's very large and/or very expensive to obtain, and it
>> might
>> or might not be of interest. Instead, the event contains a token that can
>> be
>> used to request the data if it turns out to be needed. So on receipt of
>> that
>> "data is available" event, we'll transition to a new state that can
>> determine whether it needs to obtain the data or not, and if so, to use
>> the
>> token to get it. But as it stands now, the new state doesn't have access
>> to
>> the token.
>>
>
> Ok. How do you determine whether you'll query the data source? Do you need
> to wait for more events or can this be determined with the token only?
>
>
> --
> 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
>