On Dec 5, 2009, at 7:03 PM, Michael Caisse wrote:
David Bergman wrote:
Repeating: the MSM/Statechart overlap in features and interface is quite unique to Boost. I argue that this is a bad thing. "You can never get too many goodies!" Well, I think you can. Is that situation bad enough not to be outweighed by the quite terrific design of MSM? Probably not, but I just wanted to raise the general question of duplicity (and redundancy), and also that of potentially deprecating libraries.
Back in the mid to late 90's I worked closely with a company called ObjecTime [1]. They were a telco spin-off that promoted a tool set and methodology called ROOM (Real-time Object Oriented Modeling). ROOM was very successful to the point that the ObjecTime/IBM's submission to OMG was about to be accepted as *the* real-time modeling language. Rational was distraught and quickly purchased a controlling stake of ObjecTime and integrated ROOM as the first release of UML for Real-time. What does all of this have to do with MSM/Statechart overlap? Even ObjecTime saw that not all FSM implementation/designs are created equal. While the "front end" modeling concepts provided a rich language that we could apply to various problem domains, not all domains have the same design/implementation requirements. A profitable, resource-conscience company made the choice to provide multiple FSM libraries implementing the same modeling concepts because it made good sense. I have my own graphical tool/code generator based heavily on ROOM and UML. I have considered SC and MSM as additional backend offerings to my own FSM libraries. SC is a non-starter for many of my (and my clients') targets with very small stack space. Constant creation/destruction of state objects makes me seriously question the viability of that approach for those targets. I have some small concern about the final build size of MSM; however, creating a machine in global space that is completely initialized on start-up fits perfectly with the requirements of those targets.
On the other hand, some of my targets running actual OS's with real amounts of memory create and destroy actors dynamically and perform various nifty dynamic port bindings that are much more in-line with a design/implementation utilizing virtual functions and inheritance. SC might be the perfect choice for these targets.
I have many other examples of why specifically different FSM's are appropriate for different targets... but this email is already much longer than I had intended. Interface variations make/break library adoption all the time. Design/implementation choices differentiate libraries for specific domains constantly. There is so much more than equivalent feature sets that make libraries "equivalent".
Heh, yes. I have probably used dozens of implementation of each "feature set" (regex, BNF, DFA, hash tables, other trees, graphs); but, here we are about to have two rivaling - for a lot of use cases - libraries filling the same purpose within our meta library. A clearly interesting situation. And, yes, the way to use Statechart and MSM are *much more* similar compared to Regex vs Xpressive :-) Look at my other post, containing a trivial state machine under both Statechart and MSM, and you will see that even from an interface POV, they are fairly similar. Implementation-wise they are quite different, as you noted. In fact, MSM is around six times faster than Statechart in almost all my sample scenarios, where Statechart, for instance, consumes a lot of time inside dynamic_cast. Well, I hope to remember all these points for my review of MSM :-) /David