[Feature] Clustering and non-hierarchical state relationships

[davidkpiano]

Excerpt from the original statecharts paper (emphasis mine):

The interrelationship between the states in all the statecharts presented thus far
is that of an AND/OR tree; actually an AND/XOR tree. However, there is absolutely
no deep reason for this, and statecharts need by no means be entirely tree-like.
While the human mind seems to perform well on tree-like hierarchical objects, we
definitely do not rule out clustering which is more complex. For example, Fig. 41
shows a situation in which state C has two parents. The reason for doing this might be conceptual similarities between the involved states, or merely the pragmatic
desire to economize when describing joint exits such as the two transitions appearing
in the figure. What is really happening is that states A and D are now related by
OR, not XOR. Of course, too much of this kind of overlapping will burden the
specification, with incomprehensibility possibly outweighing economy of description.
In such a case, one could resort to two copies of C.

Proposed API:
🚧 Still being determined. Open to suggestions.

More technical details here: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.221.768&rep=rep1&type=pdf

[mogsie]

It should be noted that this is from the possible extensions to the formalism chapter, and not part of the original formalism per se. SCXML and most other have them as explicitly hierarchical, so I'm not too keen on this :) "after 2s" is way higher on my list!

Other than that, I haven't experienced the need for it. Yes, there might be portions of a statechart that need to be duplicated (e.g. that α and β arrows need to be duplicated in the C state), I'm thinking that there might be better ways of dealing with that, other than overlapping states. Maybe reusable chunks of on handlers when defining the state machine itself.

const handleAlpha = { "α", "elsewhere1"}
const handleBeta = { "β": "elsewhere2" };

const states = {
  A: {
    on: handleAlpha,
    states: {
      B: {}
      C: { on: hanldeBeta}
    }
  }
  D: {
    on: handleBeta,
    states: {
      E: {}
      F: {}
      C: { on: hanldeAlpha}
    }
  }
}

The spread operator could be used to combine many signals.

[davidkpiano]

That's true - I'll mark this as Documentation so that we can just show how this can be accomplished with ES6.

[davidkpiano]

I'd still like to support this eventually - although it can be accomplished with ES6 language features, you lose the details of states being related, and that's important meta information to have when visualizing the statecharts.

[brucou]

I can;t find the reference for the paper but this feature had been investigated by Harel and they discarded it because of the added complexity, the perceived lower readability and the lack of actual use cases. aah found it :

One is the notion of overlapping states,
whereby you want the and/or state hierarchy in statecharts
to be a directed graph, not a tree. (...) We found that
the issue was pretty complicated since, e.g., overlapping
can be intermixed not only with the substate facet of the
hierarchy but also with orthogonal components. We
actually concluded that the complications might outweigh
the benefits of implementing the feature.