Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New history type 'recursive' #148

Open
InigTril opened this issue May 29, 2024 · 0 comments · May be fixed by #149
Open

New history type 'recursive' #148

InigTril opened this issue May 29, 2024 · 0 comments · May be fixed by #149

Comments

@InigTril
Copy link

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.

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

FSM_RecursiveHistory

InigTril pushed a commit to InigTril/squirrel that referenced this issue May 29, 2024
@InigTril InigTril linked a pull request May 29, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant