squirrel-foundation is a State Machine library, which provided a lightweight, easy use, type safe and programmable state machine implementation for Java.
Thanks for your work on this library which has a lot of features!
I created this issue to discuss two aspects of the history feature. I have attached a state machine diagram to illustrate my thoughts.
First, the history feature is implemented as a property of composite states instead of a pseudo-state as specified in OMG UML. I am not against that, but the documentation should be clear.
In OMG UML, the history is a pseudo-state of a composite state that is targeted by transitions. Thus one can choose to either enter the composite state via its history (transition E7), or letting it start with its initial state (transition E8). Or any other way to enter a composite state.
In squirrel, the history is a property of a composite state, so there is no choice; if you target a composite state, the history will be used, no choice. I known this can be avoided by simply targeting directly the initial state, but this could be noted in the documentation since it is not UML compliant. Actually, the current documentation is even a bit misleading since it says that the history is a pseudo-state.
Secondly, I propose a non-UML feature on the history; a new type 'HistoryType.RECURSIVE', noted H+. The existing Shallow and Deep histories let a a composite state resume in its direct last active child or in its deepest last active child, but nothing in between.
Moreover, let's say you have a composite state L1_B itself composed of two composite states L2_B and L2_C. L1_B should enter its direct last active child, and if it is L2_B, its own last active child should be activated, but if it is L2_C, it should start back to its initial state. Neither Shallow nor Deep history allow this configuration.
That's why I propose the Recursive type which will enter the last active state of each nested composite state as long as they themselves have the Recursive history property.
I am working on an implementation for my own project. My project is private, sorry, but I am willing to share the recursive history feature in a pull request if you are okay with this.
Hi,
Thanks for your work on this library which has a lot of features!
I created this issue to discuss two aspects of the history feature. I have attached a state machine diagram to illustrate my thoughts.
First, the history feature is implemented as a property of composite states instead of a pseudo-state as specified in OMG UML. I am not against that, but the documentation should be clear.
Secondly, I propose a non-UML feature on the history; a new type 'HistoryType.RECURSIVE', noted H+. The existing Shallow and Deep histories let a a composite state resume in its direct last active child or in its deepest last active child, but nothing in between. Moreover, let's say you have a composite state L1_B itself composed of two composite states L2_B and L2_C. L1_B should enter its direct last active child, and if it is L2_B, its own last active child should be activated, but if it is L2_C, it should start back to its initial state. Neither Shallow nor Deep history allow this configuration. That's why I propose the Recursive type which will enter the last active state of each nested composite state as long as they themselves have the Recursive history property.
I am working on an implementation for my own project. My project is private, sorry, but I am willing to share the recursive history feature in a pull request if you are okay with this.