On Tuesday, 22 February 2022 at 20:19:39 UTC, Chris Piker wrote:
credit you for the basic ideas
As you might have been already noted,
the key idea is to implement SM explicitly,
i.e we have states, messages, actions, transitions
and extremely simple engine (reactTo() method)
Switch-based implementation of SMs is probably normal
for text/token driven SMs (parsers),
but is not good for event/message driven SMs (i/o and alike).
Remember main OOP principle, as it is understood by Alan Key?
It is message exchanging, not class hierarchy.
In this sense this craft is OOP twice, both classes and
message exchanging.
Another important point is SM decomposition & hierarchy
(I mean master/slave (or customer/provider) relation here,
not 'A is B' relation) - instead of having one huge SM
I decompose the task into subtasks and construct various SMs.
See for example that echo-server - it has 3 level hierarchy
of states machines:
LISTENER <-> {WORKERS} <-> {RX,TX}
When I wrote the very first version of EDSM engine
(more than 5 years ago, may be 7 or so), I...
I was just stuck - how to design machines themselves?!?
Well, the engine is simple, but what next? How do I choose states?
After a while I came to a strong rule - as long as I
want to send/recv some "atomic" portion of data,
it is a state (called stage in D version)!
Then as a result of elimination of code duplcation
I "invented" kinda universal RX and TX machine and so on...
In general I've found SM very nice way of designing
(networking) software. Enjoy! :)
