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@yahoo.com> 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@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users