Thomas Klimpel wrote:
I don't think that transitions should have internal state. But I think that the user should have the possibility to model them explicitly. And this includes associating an action to them.
You can. However, not everyone liked the exact syntax the library provides in order to do that.
This paragraph was more about Dave's statement "To start with, "states handle events" is not part of the abstraction of what an FSM is." and your reaction to it. Because I'm more familiar with graphs than with finite state machines, it's easier for me to think in terms of graphs.
One of my thoughts is: "Why not? The "adjacency list" is a valid description of a graph, just as the "incidence list" is." But on the other hand, you insist to deliver each event to a state, so you somehow take the "states handle events" to the extreme. I understand that you prefer the "states handle events", because the "adjacency list" is the more efficient representation of the two.
It's not just for efficiency reasons, it's a consequence of my understanding of the FSM concept. I believe, the transitions should not be responsible for actually processing events, but instead should describe the state changes. While sometimes this is quite enough (e.g. in case of validators of different kinds), it is often needed to do other useful stuff on a certain event - IOW, to react on the event receipt. It is my belief that this is not what transitions are intended to do. That is why the proposed library is designed so that events eventually are processed in states (or put it another way, reactions on the events receipt are defined in states). However, I admit that there are possibilities that there is no need in reactions on events and the whole purpose of the state machine is to trace the transitions path, and the library is not perfectly suited for such use (although, it is still quite possible). I'm not sure if this is a significant flaw, since I, for one, have not yet encountered such a case through my experience and I can't tell how common it is.
But I get the impression that you don't honor the advantages of the "incidence list" representation enough.
I don't quite grasp what advantages these might be, with respect to the FSM concept and the proposed library in particular. I agree that in graph theory it might be very useful to embed data and meta-data (I guess, this is what you meant with "additional information") into graph edges. We both agreed that FSM transitions should not contain any data, which leaves meta-data on the table. Such meta-data may, indeed, be useful sometimes, however, I wouldn't say it is common. FWIW, this kind of information can be described with transition table entries (more precisely, their types and behavior) and thus is supported by the library. Since users can define their own transition rules and put them into the transition table, it is possible to embed any kind of information as long as it is possible in C++. However, I am not a specialist in graph theory and may well be missing something obvious. Am I?
Each "edge" or "transition" is simply a row in a table or list. Associating additional information is as easy as adding an additional column to the table. It seems like all we need to associate with a "transition" for a finite state machine is an action, but I'm no expert for finite state machine.
This part leads back to syntax issues. Well, I've already expressed my motivation for the chosen approach (for simplifying transition handlers overloading and templating), but, as I can see, this motivation is not considered significant enough by most of the reviewers. In that case I will change the transition handler specification syntax to be more close to the TMP approach.