New feature: setting the initial state when instantiating the state machine

[wizfromoz]

I'm trying to implement a persistent state machine. One of the requirements is on powerup the state machine goes straight into the last saved state, without any on-entry actions being invoked. Looking into the implementation, I can't see how this can be done with scxmlcc generated state machine directly.

I can think of work-arounds, but it would greatly simplify things if the state machine constructor could accept the initial state as a parameter.

[sstiller]

That's not in the SCXML standard. Is it somehow related to #23?

constructor could accept the initial state as a parameter

That could become interesting with parallel (sub)states.

[wizfromoz]

I wasn't aware of the element, but after reading about it, that's precisely that. There's an event (going into hibernation) that forces the state to be recorded and another event that should should restore into that state. The specification says "SCXML processor must record ...". I suppose that the state machine implementation must provide hooks that do the actual persisting? Anyway, is this on the table for consideration?

I was looking at using new_state() to set the initial state by directly assigning it to the model.cur_state. The states that are in the leaves of the state tree would have an action that, on receiving save event would persist their id. Then, on restore event, I would set the current state to the stored one. Any reason why this couldn't work?

[jp-embedded]

It has not been at the table before now.

With a persistant state machine, I guess the data model should be stored as well.

If the goal of your persistant state machine is to be able to re-instantiate a machine into the same state as it was before? This is not the same as the history state which is kind of 'return to the state that was active before', which would not need to be persisted other than in the current instance

[jp-embedded]

Also as sstiler mentions, we should be careful about features that does not follow the standard.

Maybe this persistence could be implemented by making a class that inherits the state machine. Then you can overload the init method at set your initial state there - just a quick thought. I am on vacation rigtht now 😊

[wizfromoz]

Thanks Jan, I like the idea about overloading init method. It will do for now, until you get around implementing tag, which is standard, and would help with persisting the state machine.

From: Jan Pedersen notifications@github.com Sent: Wednesday, 24 July 2019 5:58 PM To: jp-embedded/scxmlcc scxmlcc@noreply.github.com Cc: Durovic, Milan Milan.Durovic@aristocrat.com; Author author@noreply.github.com Subject: [EXTERNAL] Re: [jp-embedded/scxmlcc] New feature: setting the initial state when instantiating the state machine (#103)

Also as sstiler mentions, we should be careful about features that does not follow the standard.

Maybe this persistence could be implemented by making a class that inherits the state machine. Then you can overload the init method at set your initial state there - just a quick thought. I am on vacation rigtht now 😊

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/jp-embedded/scxmlcc/issues/103?email_source=notifications&email_token=ABZF3Z2IAW57ZLLOFEMJDITQBADQXA5CNFSM4IFT7BHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2VQEYQ#issuecomment-514523746, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABZF3Z4TZW2GVVQN6NAQKFDQBADQXANCNFSM4IFT7BHA.

---

IMPORTANT CONFIDENTIALITY NOTICE:

This e-mail (including any documents referred to in, or attached to, this e-mail) may contain information that is personal, confidential or the subject of copyright, privilege or other proprietary rights in favour of Aristocrat, its affiliates or third parties. This e-mail is intended only for the named addressee. Any privacy, confidentiality, legal professional privilege, copyright or other proprietary rights in favour of Aristocrat, its affiliates or third parties, is not lost nor waived if this e-mail has been sent to you in error.

If you have received this e-mail in error you should: (i) not copy, disclose, distribute or otherwise use it or its contents without the consent of Aristocrat or the owner of the relevant rights; (ii) let us know of the mistake by reply e-mail or by telephone (AUS +61 2 9013 6000 or USA +1-877-274-9661); and (iii) delete it from your system and destroy all copies.

Any personal information contained in this e-mail must be handled in accordance with applicable privacy laws.

Electronic and internet communications can be interfered with or affected by viruses and other defects. As a result, such communications may not be successfully received or, if received, may cause interference with the integrity of receiving, processing or related systems (including hardware, software and data or information on, or using, that hardware or software). Aristocrat gives no assurances and accepts no liability in relation to these matters.

If you have any doubts about the veracity or integrity of any electronic communication we appear to have sent you, please call (AUS +61 2 9013 6000 or USA +1-877-274-9661) for clarification.

[jp-embedded]

Good to hear.

I am currently working on another issue with handling conflicting transitions in parallel states

But eventually, the history tag will be implemented.