Boost logo

Boost :

From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2008-09-02 13:15:45

Thomas Klimpel wrote:
> Andrey Semashev wrote:
>>> But how can I specify the "transition action", if not by
>>> overriding the "transit" method?
>> As I said, if you need some non-trivial (i.e. something more
>> complex than a mere call to switch_to), you have to implement the
>> transit handler. Otherwise, you don't have to do that and you get
>> precisely what the TMP solution provides.
> Your answers confirm my initial statement: "The modeling of the
> "transition" concept could and should probably be improved."

I'm just trying to understand how, exactly, it should be improved. Your
previous posts were referring to the necessity to override transit
handlers in order to define transition actions. I confirmed that but
added that it is not worse than other solutions mentioned. So, I don't
see how and why this particular feature should be improved.

> Also, your statement "you get precisely what the TMP solution
> provides" is misleading. It's easiest for me to explain this with an
> example from graph theory. A graph can be described by an "adjacency
> list", but it can also be described by an "incidence list". The
> state-based approach of the FSM library corresponds to the
> description of a graph by the "adjacency list". The transition-based
> approach of the TMP solution corresponds to the "incidence list". The
> description by an "adjacency list" will often be more efficient than
> the description by an "incidence list", but the "incidence list"
> makes it easy to associate additional information to the edges of the
> graph. You basically claim that you also support the "incidence list"
> approach, but you don't provide support for associating additional
> information to the edges of the graph, because you consider this "too
> complex".

Yes, however, I'd rather say, it would be difficult to use an FSM with
transitions that have internal states, while simplicity being one of the
primary goals of the library.
To my mind, this is quite an academical question, whether transitions
should have internal data or be stateless. After all, transitions model
actions, not the state of the machine. But even then, you still have
access to states from the transition handler, so you can associate data
to the transition, if you really need it.

Boost list run by bdawes at, gregod at, cpdaniel at, john at