Jeff Garland wrote:
I guess you mean the increase in complexity compared to the traditional ways of implementing FSMs (nested switch case, state pattern, etc.). I think there's an increase only for small simple machines, like StopWatch. I think there is a (sometimes dramatic) reduction of complexity for bigger (and more real-world) machines.
I addressed what I meant by complexity in my response to Darryl. The thing is since we don't have an example of bad code that can be simplified by an fsm to compare agaisnt in the docs and we can all think of easier ways to write the StopWatch I worry that people will be put off.
The tutorial is primarily addressed to people who already have had exposure to FSMs (and also had to implement them one way or another). You are right, a beginner with only theoretical or even no prior knowledge about FSMs would probably shake his head before even following through the StopWatch example. I've spent quite some time thinking how I could also address newbies but have come to the conclusion that this would require a separate document at least as large as the tutorial.
So I think the remedy is to just say that stopwatch is too simple to bother with fsm, but with bigger state machines there is significant advantage.
I will try to do that, in particular I'll try to explain more thoroughly the issues with global variables.
Currently there's no code generation and I doubt there'll ever be such a tool (I personally wouldn't use it). IMHO, a reverse engineering tool would be *much* more useful.
Perhaps. If there was an XMI (UML to fsm generator or another state definition language) it might be easy to generate.
I think that a graphical state chart --> code generator surely helps beginners to get started. It provides them with *skeleton* code very soon. However, the generated skeleton is unlikely to do anything useful (I expect the generated code to be similar to the one right before the "State-local storage" heading). To get the code to do something, the programmer needs to fill statements into the action bodies. To be of help after doing so, the generator needs to be pretty sophisticated. To me, this seems too much work for something that can just as easily and probably faster be done manually. Sure, the initial effort to get something to compile is a little higher without a generator, but only a little.
You usually make variables as local as you can (i.e. push them towards innermost states as much as possible). There would be more to say here but I'll be off soon. More on this later...
Ok, good. I think this sort of discussion would be useful in the FAQ or somewhere in the docs.
Agreed. BTW, I think Darryl's take on variable scoping and heuristics hit the nail on the head. Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.