From 14028aee428c135211e33df77c1bee2fdc128f6e Mon Sep 17 00:00:00 2001 From: Raimo Niskanen Date: Wed, 24 Feb 2016 16:36:24 +0100 Subject: Ditch PrevState StateName/4 -> StateName/3 handle_event/5 -> handle_event/4 --- lib/stdlib/doc/src/gen_statem.xml | 70 ++++++++++++++------------------------- 1 file changed, 24 insertions(+), 46 deletions(-) (limited to 'lib/stdlib/doc/src/gen_statem.xml') diff --git a/lib/stdlib/doc/src/gen_statem.xml b/lib/stdlib/doc/src/gen_statem.xml index 1e41d616e9..f21610d14c 100644 --- a/lib/stdlib/doc/src/gen_statem.xml +++ b/lib/stdlib/doc/src/gen_statem.xml @@ -62,12 +62,12 @@ gen_statem:stop -----> Module:terminate/2 gen_statem:call gen_statem:cast erlang:send -erlang:'!' -----> Module:StateName/4 - Module:handle_event/5 +erlang:'!' -----> Module:StateName/3 + Module:handle_event/4 - -----> Module:terminate/3 -- -----> Module:code_change/3 +- -----> Module:code_change/4

Events are of different types so the callback functions can know the origin of an event @@ -91,28 +91,22 @@ erlang:'!' -----> Module:StateName/4 is state_functions the state has to be an atom and is used as the state function name. See - - Module:StateName/4 + + Module:StateName/3 . This gathers all code for a specific state in one function and hence dispatches on state first. Note that in this mode the callback function - - Module:code_change/4 - makes the state name code_change - unusable. Actually you might get away with using it - as a state name but you will have to find a way to separate - the two callback roles e.g by observing that you can force - argument 3 into having different types for the different roles. - This is a slippery slope, though. It is easier - to simply not use code_change as a state name. + + Module:terminate/3 + makes the state name terminate unusable.

When callback_mode is handle_event_function the state can be any term and the state function name is - - Module:handle_event/5 + + Module:handle_event/4 . This makes it easy to dispatch on state or on event as you like but you will have to implement it. @@ -120,12 +114,6 @@ erlang:'!' -----> Module:StateName/4 states so you do not accidentally postpone one event forever creating an infinite busy loop.

-

There is a small gotcha in both callback modes regarding - the state undefined that is used as the previous state - when the first state function is called. So either do not - use undefined as a state, or figure out - the implications yourself. -

The gen_statem enqueues incoming events in order of arrival and presents these to the state function @@ -378,14 +366,14 @@ erlang:'!' -----> Module:StateName/4 The state has to be of type state_name() and one callback function per state that is - - Module:StateName/4 - is used. This is the default. + + Module:StateName/3 + is used. handle_event_function The state can be any term and the callback function - - Module:handle_event/5 + + Module:handle_event/4 is used for all states. @@ -1054,9 +1042,10 @@ erlang:'!' -----> Module:StateName/4 CallbackMode selects the callback_mode(). of the gen_statem. - State is the state() - of the gen_statem and - Data the server data() + State is the initial + state() + and Data the initial server + data()

The Actions are executed when entering the first @@ -1076,11 +1065,10 @@ erlang:'!' -----> Module:StateName/4 - Module:StateName(EventType, EventContent, - PrevStateName, Data) -> Result + Module:StateName(EventType, EventContent, Data) -> Result Module:handle_event(EventType, EventContent, - PrevState, State, Data) -> Result + State, Data) -> Result Handle an event @@ -1088,10 +1076,7 @@ erlang:'!' -----> Module:StateName/4 event_type() EventContent = term() - PrevStateName = - state_name() - - PrevState = State = + State = NewState = state() Data = NewData = @@ -1109,9 +1094,9 @@ erlang:'!' -----> Module:StateName/4 cast/2 or as a normal process message one of these functions is called. If callback_mode - is state_functions then Module:StateName/4 is called, + is state_functions then Module:StateName/3 is called, and if it is handle_event_function - then Module:handle_event/5 is called. + then Module:handle_event/4 is called.

If EventType is {call,Caller} @@ -1126,13 +1111,6 @@ erlang:'!' -----> Module:StateName/4 reply(Caller, Reply) .

-

PrevStateName and PrevState are useful - in some odd cases for example when you want to do something - only at the first event in a state, or when you need to - handle events differently depending on the previous state. - Note that when gen_statem enters its first state - this is set to undefined. -

If this function returns with a new state that does not match equal (=/=) to the current state all postponed events will be retried in the new state. -- cgit v1.2.3