FSM and changing state data onTransition

[Pavel Chlupáček]

Hi is there any simple way how to change state data in in onTransition handler in FSM?

Thanks

Pavel

[Derek Wyatt]

As far as I know, you can't. The TransitionHandler is defined as PartialFunction[(S, S), Unit], so anything you want to do like that would probably have to be done "sneakily", if at all, so it's probably not a wise idea...

What's the use case? I've never seen a need to actually change the data during a transition; perhaps there's another way to do what you're asking.

> --
> You received this message because you are subscribed to the Google Groups "Akka User List" group.
> To post to this group, send email to akka...@googlegroups.com.
> To unsubscribe from this group, send email to akka-user+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/akka-user?hl=en.
>

[Pavel Chlupáček]

Derek,

Lets assume you have one state (A) which can transition to state (B) and (C) . Now State (A) has a reference to (Option[String]) in stateData. State (B) and (C) should have this set to None. so ideal way would be to do something like

onTransition {
case A -> _ => nextStateData = nextStateData(aopt=None)
}

onTransition {
case A->B => //b stuff -- when needed
case A->C => //c stuff -- when needed
}

Obviously the workaround is to do

goto(B) using stateData.copy(aopt=None)

and

goto(C) using stateData.copy(aopt=None)

which I simply don't like because its same logic on two places of code.


Does this make any sense? Do you have some nicer way to go around?

Tx

P.

[Derek Wyatt]

Ok, I get it.

Well, what you want, I don't believe you can have.  You have to remember that all matching onTransition blocks are executed, not just the first match.  It's quite likely that, were this available as a feature, understanding the resulting data after all transitions have been applied, might get very difficult.  That's a high price to pay.

I think the best solution to your problem is to fall back to the same ol' solution to these problems: encapsulate.

def gotoUsingNone(state: State) = goto state using stateData.copy(aopt = None)

I'm sorry it's not exciting :)

[Pavel Chlupáček]

Yup, the function makes sense. 

And yes I assume the all transition blocks occur (thats why I have put two handlers there, not single one). The desired functionality is to do the cleanup in A->_ case (essentially saying do this always for everyone leaving the A state) and then do some notifications or cleanup or whatever in A->B and A->C ... This may be much more clear to read than all these def clearNone().andThenSetSome() ... chains. I think it is style of preference maybe. 

Just think of this like more clear way of expresing the intentions

//Always when leaving state make sure data are consistent and put all assertions here

onTransition {

case A-> _ => //do cleanup

}

//when entering state make sure all data are consistent and do all assertions

onTransition {

case _ -> A => //do initialization

}

when (A) {

case Event(msg:MsgOne, data) => {

goto(B).assureADataAreSetCorrectly().using (....)

}

....... many more messages where I may go to B, C, D, E, F and everywhere I have to repeat goto(XYZ).assureADataAreSetCorrectly()

}

def assureADataAreSetCorrectly()

I can live without it, but would not believe there is a big deal to have this feature in. looking on what def nextState is, I think def nextState_= would solve the problem. In fact you can have this if one prefer having vars holding these state data, but this seems to me broken as this tights the implementation to actual instance and may be prolly broken design when migrating state actors over cluster in future....

Cheers, and thanks for suggestion

Pavel. 

[Derek Wyatt]

I dunno… personally, if it were available, I wouldn't use it.  The way it's done now makes my code easy to reason about, and that's the win I'm looking for.

But I get what you're saying.  I just think that such a feature would open the doors to some pain… I don't like pain :)