gotoHistoryState()

[rledisez]

I think the developer does not have to choose between gotoState() or gotoHistoryState(). It is up to the statechart manager to handle that.

Adding two booleans to Ki.state could avoid the use of the method gotoHistoryState() :

A: Ki.State.design({
    initialSubstate: 'A1',
    /** PROPOSAL **/
    history: YES,
    historyRecursive: NO,

    A1: Ki.State.design({
    }),

    A2: Ki.State.design({
    }),
}),

[FrozenCanuck]

Handling whether to use a state's history is based on the a state transition from another state, not the state itself. This concept follows what is in Harel's Statechart paper. When designing your statecharts, a transition can go to a state itself, it's immediate history, or its history in a recursive fashion. Therefore the history and historyRescusive properties force all transitions to adhere to one way of acting on a state during the transition process, which is not flexible.

[rledisez]

Please correct me if I'm wrong. As far as I understand the Harel's Statechart paper, I think there is two possibilities :

• MUST use history
• CAN use history

In the Harel's Statechart paper :

• figure 10a is a CAN. In this figure, event "a" choose to use history. The method call is gotoHistoryState('alarm 1')
• figure 10b is a MUST. In this figure, event "a" uses history, without knowing it. The method call is gotoState('alarm 1') but the history had to be used.

history and historyRecursive are for the case MUST. It was not clear in my first message (even not in my head).

[FrozenCanuck]

I understand what you mean now regarding CAN versus MUST. In the case of fig 10(b) the intent is that the initial substate for state "alarm 1" is its history state (non-recursive) instead of being explicitly either state off or state on. Therefore the state transition is really about what is the initial substate is when entering a state: an explicit substate, its history state non-recursive; its history state recursive. In the case where the initial substate is to be a state's history state and the history state is null, then the default is to enter an explicit substate. In fig 10(b) the default state to enter is the "off" state.

[FrozenCanuck]

I was giving some more thought to the history state, and since it is legit to set the initial substate to be a state's history state, then it makes sense for Ki to address this scenario. Because there is already a initial substate property, it makes sense to continue to use it when you want to specify that a state's history state should be the initial substate. The initial substate property would likely work as such:

Ki.State.design({
  initialSubstate: Ki.HistoryState.design({
    isRecursive: NO, // Values: [ YES | NO ]
    defaultState: 'foo' // Name of any immediate substate
  }),

  foo: Ki.State.design({ ... }),

  bar: Ki.State.design({ ... })
});

The Ki.HistoryClass class has two properties: isRecusive and defaultState. The statechart is responsible for configuring the state's initial substate to actually be the history state.

[rledisez]

Your solution is much more elegant than my two booleans. I'm waiting for the commit :-)

Thanks.

[FrozenCanuck]

Has been implemented :-)