Re: [boost] [msm] Review

Subject: Re: [boost] [msm] Review
From: David Bergman (David.Bergman_at_[hidden])
Date: 2009-12-06 16:49:10

On Dec 6, 2009, at 4:39 PM, David Bergman wrote:

> On Dec 6, 2009, at 4:28 PM, Michael Caisse wrote:
> 
>> David Bergman wrote:
>>> 
>>>> I mean there's no headroom here like "For my use cases ..." or "To me ...". In absence of such qualifiers the reader must assume that you think that from a purely functional POV the two libraries are exchangeable for *all* possible uses. Add your remarks regarding library removal and the reader must IMO come to the conclusion that you think *all* users will be better served with MSM once compilers catch up. For sure, MSM *does* look terrific and may well satisfy a good majority of FSM implementers but there are certain use cases (e.g. multi-TU FSMs) that MSM will probably never support. OTOH, Statechart will e.g. never be able to guarantee O(1) dispatch.
>>>> 
>>>> So yes, there *is* overlap but it is certainly far from total, right?
>>>> 
>>> 
>>> Not far from, no. If you bring up one feature, multi-TU FSM, I would not call that "far". The overlap is 95%. No?
>>> 
>>> Just look at the feature list of your own library, Statechart, as described in the Overview section. Which one of those features does *not* apply to MSM?
>>> 
>>> /David
>>> 
>> 
>> Just to be clear David... A couple people have now brought up that the actual implementation
>> (not the feature set) is very much a differentiator for different targets. You continue to
>> point at "features". Do you not think that the implementation of a library is a consideration
>> for different targets?
> 
> Yes, of course, which I have stated in various posts of mine.
> 
> I *know* that the implementations differ, but that was not what we were discussing here, was it? We are discussing whether the feature sets and interfaces are far apart or not.

Additionally, for targets (i) not having many transitions per second and/or (ii) not having severe memory (or compiler/standard library...) constraints, the run-time characteristics of these two libraries are good enough, i.e., the implementations would *not* be a differentiator when choosing an FSM library for future such Boost developers. I contend that this set of developers, or, rather problem domains, constitute the vast majority of FSMers. That contention might be wrong, and even if it were right, that would not make much difference to those (a) with high-frequency transitional needs (probably picking MSM) or (b) those with huge transition tables, crippled compilers or "crippled" deployment targets (I did not call them such when I worked much more with embedded development ;-)) (probably picking Statechart.) It is just for the "rest of us" that the choice would be much a matter of interfacial matters or even aesthetics :-)

/David