From f3f2b83e873592bcec47431a787c7cfffdd60685 Mon Sep 17 00:00:00 2001 From: Raimo Niskanen Date: Tue, 25 Oct 2016 09:29:21 +0200 Subject: Clarify the chapter 'Postponing Events' (ERL-284) --- system/doc/design_principles/statem.xml | 29 ++++++++++++++++++----------- 1 file changed, 18 insertions(+), 11 deletions(-) (limited to 'system/doc/design_principles/statem.xml') diff --git a/system/doc/design_principles/statem.xml b/system/doc/design_principles/statem.xml index bece95e6b8..f627145f9f 100644 --- a/system/doc/design_principles/statem.xml +++ b/system/doc/design_principles/statem.xml @@ -1015,17 +1015,24 @@ open(cast, {button,_}, Data) -> ... ]]>

- The fact that a postponed event is only retried after a state change - translates into a requirement on the event and state space. - If you have a choice between storing a state data item - in the State or in the Data: - if a change in the item value affects which events that - are handled, then this item is to be part of the state. -

-

- You want to avoid that you maybe much later decide - to postpone an event in one state and by misfortune it is never retried, - as the code only changes the Data but not the State. + Since a postponed event is only retried after a state change, + you have to think about where to keep a state data item. + You can keep it in the server Data + or in the State itself, + for example by having two more or less identical states + to keep a boolean value, or by using a complex state with + callback mode + handle_event_function. + If a change in the value changes the set of events that is handled, + then the value should be kept in the State. + Otherwise no postponed events will be retried + since only the server Data changes. +

+

+ This is not important if you do not postpone events. + But if you later decide to start postponing some events, + then the design flaw of not having separate states + when they should be, might become a hard to find bug.

-- cgit v1.2.3