Re: [boost] [review] FSM Second Call for Reviews

From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2008-09-01 09:25:12

Andrey Semashev wrote:
> Jeff Flinn wrote:
> 
>>> What is your evaluation of the design?
>>> What is your evaluation of the documentation?
>> My view of the design is limited to what is described in the
>> documentation. I was a little dismayed that some of the basic features
>> that I needed are considered Advanced features such as sharing state and
>> accessing the current state from outside the state machine. These are
>> very easily accomplished in the TMP and StateChart libraries.
> 
> It's just a name for the section. Everything that didn't fit into
> Tutorial went into that section.
> 
>> The
>> section on accessing state is not sufficient for me to determine which
>> state the fsm is in between calls to process().
> 
> Huh? There is a section that tells precisely how to do this. The
> is_in_state and get_current_state_type methods fill your requirement.

Ok, not sure why I had trouble reading through that earlier, other than 
I had a hard time finding this section whenever I went to look for it. 
Perhaps if you moved the Table of contents to the top of the docs, as it 
is it gets lost in the clutter.

So so I would use is_in_state<extracted_triplet>(); in the 
extractor::extracted method?

>> The data sharing
>> approach between sibling states using a virtual base class is
>> perplexing... there's no discussion of just what is the structure of the
>> state machine.
> 
> Actually, this feature is one of those I love in the library.
> 
> The description of the structure is given in the "Common data and
> methods among states" section. I admit, however, there's no graphical
> representation of the design, but if I drew precisely what the structure
> is, I think, it would confuse you even more.

Perhaps a Design/Rationale section would better convey that this section 
describes the overall architecture of the system.

>>> Do you think the library should be accepted as a Boost library?
>> No. I'd prefer that the performance and missing functionality be added
>> to improve the existing StateChart library, and/or a true transition
>> table approach be provided ala the TMP book's transition table.
> 
> I don't think that with current implementation approach Boost.StateChart
> can be optimized to the degree of Boost.FSM. As for TMP approach, I've
> shown that it is representable with Boost.FSM.

What leads you to the conclusion that StateChart's performance could not 
  be improved to that of FSM's?

Can you direct me to that discussion/presentation on emulating the TMP 
approach?

>> I
>> dislike FSM's verbose interface along with it's procedural leaning
>> paradigm.
> 
> Having a look at your example, I don't find Boost.FSM portion to be much
> more or less verbose than others.

I'd say it's on par with StateChart. Like StateChart, there's 
boilerplate repetition of base classes, "void on_process", and 
"switch_to" not present in the TMP approach.

Jeff