I can't wait for the next post :-) ! Are their any studies that confirm: "events + state machines > others" ? Thx again !
As for events, Joe Armstrong's doctoral thesis comes to mind. As for state machines, I don't really know. Let me know if you find something.
John Ousterhout of Tcl (among other things) fame:
http://www.cc.gatech.edu/classes/AY2009/cs4210_fall/papers/ousterhout-threads.pdf
An excellent article. I am definitely gonna use those ideas for my projects.
Anyway, I was fed up with doing the same stuff all the time, so I wrote go-statemachine. I am going to use it for implementing objects that are supposed to act as small synchronous event loops, and that is basically what those state machines are, right? Feel free to comment on the library, it's not like written according to this article or super optimized, it is for my purposes. But I still think that it might be useful for someone. I wrote it like today, so it can and will change, but you know, it's there ;-)
Regards,
Ondra Kupka
One thing that comes to mind when looking at the example is that the body of the state machine should be organised by states first, by events second, not the other way round.
Anyway, I am planning to write down my take on state machine implementation details in the next blog post once I have some time free. We can discuss it then.
Good article.
I think events are superior for several reasons:
1. They can be pretty easily logged. In your event dispatch simply log each event with its receiver.
2. They can have aspect-like rules attached. For instance: Any event which starts with 'set' should check the user who created it for authorization.
3. They can handle delegation by forwarding events to other objects. This is great for avoiding unnecessary inheritance.
4. Composition of events. Chain multiple events to fire in sequence.
Event driven architectures and state machines are great to have in your toolbox, and this is a pretty good introduction to them, but I think your explanation of state machines does them a disservice.
Although the typical implementation is a bit less formal, these kinds of state machines *are* related to the finite state machines of automata theory, and that's a *good* thing. Formalizing things, at least to some degree, helps you think about them in a structured and well-understood way. That's because they're based on simple theoretical constructs, not in spite of it.
I all all for finite state automata. However, I wanted to make it clear it's not the same thing. Formal FSMs have, by definition, finite state (bacically a single enum) whereas the entities called "state machines" in engineering practice often have complex and varied state.
Any ETA for the follow-up article? Can't wait for it :-)
This is a pretty fantastic read. I've actually stumbled in this direction completely by accident when doing WinForms programming in .NET. I simply have sought out the simplest thing that could possibly work, and it ends out almost identical to your tree structure, where there is a main controller object that communicates via function call to its subordinates, who in turn raise events when something "interesting" happens.
All of the code that I see that fails to follow this pattern ends out a tangled mess of uh… "logic". It's never really clear who is doing what or responsible for this or that.
Fantastic article. I have used event driven state machines extensively in the past and found it to be a fantastically easy system for creating logical flows through the system. You call them narratives and think that that is entirely accurate. You can understand the story of what happened by the events that arrive and knowledge of the states of the machines when that event arrived.