Initialization of state properties, and 'keeps history'

[jakhog]

As far as I can remember from our discussion last week regarding state properties, the proper behaviour was that their value was initialized when the containing state is entered (I guess before 'on entry' is executed). Unless: 'keeps history' is set.

I am a bit confused by this, does this also apply to the substates of a composite/region as well, that they keep their property values upon re-entry? E.g.:

statechart init State1 keeps history {
  property A : Int = 1

  state State1 {
    property B : Int = 2
       ...
  }

  composite state State2 init State3 {
    property C : Int = 3

    state State3 {
      property D : Int = 4
        ...
    }

      ...
  }
}

Which properties keep their values between transitions here? A-yes and D-no is easy I guess, and as far as I understand, B-yes and C-no. It feels a bit strange though...

IMHO, it would be better if the properties are initialized when the instance is initialized, to their explicit init value (or the default which depends on target platform). If the user wants to re-set values whenever the state is re-entered, it could be done explicitly in the 'on entry'.

If I haven't completely misunderstood, the current behaviour (reset before entry) feels more restrictive than forcing the user to do it in 'on entry'.

What do you think? (Keep in mind that I am no UML-guru, so there might be some standard semantics that I don'w know of)

[brice-morin]

Well, there we might want to check the UML specs... But I would tend to say A-yes, C-yes and no for the rest.

[jakhog]

Well that makes event less sense for me, why does it keep the value for C when State2 has no 'keeps history'?

[brice-morin]

Ah well, I missread the example (I though the composite was also keeps history), which was simpler than I though. Then only A is yes. Not that UML has the notion of deep and shallow history (if I am not mistaken...). I guess we should just choose one semantics.

[brice-morin]

So if we want a deep history, we need to specify all states as keep history. But I do not think we can have atomic state to keep history (i.e. the value of their attributes). It is just for composite/regions (for their attributes, but also for the current/initial state). Seems like we haven't completely thought that through for properties. Or we can have deep history by default, but then it makes it a pain to implement shallow history (then one have to manage the history by hand in on entry/on exit, etc)

[jakhog]

Hmm, but then this doesn't seem so useful to me.

So even though a composite that keeps history will re-enter into the last state, that last state will not keep its properties?

[brice-morin]

cf my comment above

[jakhog]

By deep history you mean that all states keep their history, and by shallow history you mean?

[brice-morin]

Deep = recursive (all the states of this composite/region will keep history): ABCD-yes Shallow = only applies to this composite/region. This composite/region will use current state as initial state and not re-initilize properties. But the states and regions inside will not keep history, unless explicitly specified. A-yes, BCD-no

[brice-morin]

Or we could as well introduce keeps history and keeps deep history in the language. I am not quite sure how the different compilers currently handle history (deep or shallow by default, what about properties?)

[ffleurey]

I thinks that to be consistent with UML, it should be shallow. If you need deep you have to repeat it. We should add some tests to make sure all compilers are consistent with that. For the properties, I would say that they should keep their values as well but I am not sure what the compilers currently implement, should be tested as well... Let's close this issues when the tests are added.

[brice-morin]

Yes, if we have shallow history, we can have deep history, but not the other way round. Better keep the flexibility and avoid being redundant. But then I guess we should also allow keep history on atomic states so that an atomic state can preserve the values of its properties if we re-enter it later on. @jakhog can you look into modifying the language to support that?

As for properties and history, I guess we will have some suprises :-) I cannot remember what I did in Java and JS, but I guess state properties are not influenced by the history at all (either always re-init or never).

@jakhog can you make some additional tests covering the points we discussed?

[brice-morin]

@ffleurey Note that it seems UML has both notions of shallow and deep hisotry, denoted H and H*. But I'm fine with just shallow