In the current codebase we have EditLabel StateID String, which suggests that the Machine type provides an interface for entering an edit state when a StateID is selected. However, the way its used in Building.elm disobeys this assumption, as the ID can be both a StateID and TransitionID:
|
EditLabel _ lbl -> |
|
let |
|
newState = |
|
case model.machineState of |
|
EditingStateLabel st _ -> |
|
EditingStateLabel st lbl |
|
|
|
EditingTransitionLabel tr _ -> |
|
EditingTransitionLabel tr lbl |
|
|
|
_ -> |
|
model.machineState |
|
in |
|
( ( { model | machineState = newState }, pModel, sModel ), False, Cmd.none ) |
In fact, it just ignores the ID and instead checks the state of the machine. In npda-v3, I refactored this into EditStateLabel and EditTransitionLabel, which then has a one-to-one relationship to EditingStateLabel and EditingTransitionLabel respectively.
In the current codebase we have
EditLabel StateID String, which suggests that the Machine type provides an interface for entering an edit state when a StateID is selected. However, the way its used in Building.elm disobeys this assumption, as the ID can be both a StateID and TransitionID:finsm/src/Building.elm
Lines 347 to 360 in 398f02c
In fact, it just ignores the ID and instead checks the state of the machine. In npda-v3, I refactored this into
EditStateLabelandEditTransitionLabel, which then has a one-to-one relationship toEditingStateLabelandEditingTransitionLabelrespectively.