Closed fungiboletus closed 5 years ago
As #203 points out already, it is probably more correct to re-initialize them when we re-enter the state (except if the composite state keep history). We could still keep those properties global in the generated code (as I suspect it makes it simpler in the compiler), but we should be able to insert the re-initialization code systematically.
As you found the official work-around, I assume the fix is not completely urgent :-) But we should fix it
Also related to #197
The general issue of re-initializing properties gets more complex with keeps history
. But it seems that discussion tended towards a shallow history. But we did not conclude anything on whether or not atomic states should be allowed to keep history or not. @ffleurey ???
Anyway, in your case (without history), properties should indeed be reset.
But I would rather fix the general issue, rather than just the special case. IMHO, if we go for shallow history AND allow atomic state to have history (AND reset by default is no history), I think we can then have a quite flexible strategy. @ffleurey ???
Your issue should be fixed (for all compilers).
Note that the commit just fix your issue, i.e. reset properties of composite states that do not have history.
Considering the following composite state :
I did expect numberOfLapins to be initialised to 0 everytime my state machine enters the composite state Lapin. But it does not. When I look at the generated code in JavaScript, the property is actually global and initialised only once per instance like every other property.
I guess this is normal considering the current implementation, but is it the correct behaviour ?
The following code works as I expect it to.