Commons SCXML
  1. Commons SCXML
  2. SCXML-30

Better handling of parent/child relationsships

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.5
    • Fix Version/s: None
    • Labels:
      None

      Description

      The nice thing about Statecharts is its hierarchical structure. However, it is far too easy to build incomplete models, e.g. use addChild but forget setParent. I notice that some add methods automatically set the parent (opposite relation), and I suggest that this is done consistently throughout the model classes. This also goes for methods like State.setParallel and Parallel(TransitionTarget).setParent.

        Activity

        Hide
        Ate Douma added a comment -

        Resolving this issue.
        I went through all the model classes and AFAICT this improvement has been taken care of properly some time before.

        Show
        Ate Douma added a comment - Resolving this issue. I went through all the model classes and AFAICT this improvement has been taken care of properly some time before.
        Hide
        Rahul Akolkar added a comment -

        Makes good sense to do this. One can think of two "views" of state machines from a Commons SCXML perspective:

        (a) A document-centric view: This is the n-ary tree represented by the SCXML document. The top-down relationships from document root are important
        (b) A engine-centric view: This is an intricate graph with all the wires between transition targets and initials and histories drawn out on top of the n-ary tree in (a)

        For version 0.5, the focus has been to take (a) and the wiring needed to transform it into (b) was done as a separate step. While this will continue to hold to some extent, the consistency and conveniences needed for procedural tweaking of the object model (such as setting symmetric references) are definitely desirable, though it might mean we lose the side-effect free setters in some cases. While it may not be obvious, SCXML-23 has the beginnings of such an effort.

        I am setting the fix version to 1.0 primarily because, on a strict prioritization basis, this lags behind other things I want to do. However, if anyone fancies a tested patch, there is no reason not to apply it immediately.

        Show
        Rahul Akolkar added a comment - Makes good sense to do this. One can think of two "views" of state machines from a Commons SCXML perspective: (a) A document-centric view: This is the n-ary tree represented by the SCXML document. The top-down relationships from document root are important (b) A engine-centric view: This is an intricate graph with all the wires between transition targets and initials and histories drawn out on top of the n-ary tree in (a) For version 0.5, the focus has been to take (a) and the wiring needed to transform it into (b) was done as a separate step. While this will continue to hold to some extent, the consistency and conveniences needed for procedural tweaking of the object model (such as setting symmetric references) are definitely desirable, though it might mean we lose the side-effect free setters in some cases. While it may not be obvious, SCXML-23 has the beginnings of such an effort. I am setting the fix version to 1.0 primarily because, on a strict prioritization basis, this lags behind other things I want to do. However, if anyone fancies a tested patch, there is no reason not to apply it immediately.

          People

          • Assignee:
            Unassigned
            Reporter:
            Hallvard Trætteberg
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development