Chris Russell wrote: > [snip] > Andreas wrote: > >> So, IMO there's no need for boost::fsm to provide communication >> protocol primitives, because their functionality is pretty >> orthogonal to what my library does. Users would want to use what >> they're accustomed to. Most would presumably use boost::function. >> > > ... but given some set of two or more FSM's for which you want to > define a new protocol, it seems like some sort of concept checking > would be useful. This will likely have some impact on the design of > the FSM framework > itself - maybe... Perhaps it's just some metadata that non-invasively > characterizes the FSM? If the later, then Andreas' assertion that the > FSM > lib doesn't need to support protocol primitives seems reasonable.
Ok, I see that concept checking could be helpful... > I've been staring at the Wikipedia sections on Morphisms [1] and Group > Theory [2] looking for a suitable nomenclature for describing these > protocol concepts. Basically my idea is that the actual protocol > would formally specify what flavor of *morphism it's attempting to > establish and use information from FSM's in the group to determine if > such a mapping is possible (the concept check) and if so, affect the > mapping generically somehow (i.e. the protocol itself doesn't doesn't > get involved with event types and data semantics directly). Unclear > to me if this is done at compile time, runtime, or <gasp> both... > > What do you guys think of these ideas? Errr, while I got what a group is I don't really get what a *morphism is. The description is too formal for me and the examples don't help either. Moreover, I also fail to see the connection between groups and FSMs. Have I been drinking too much lately ;o)? Regards, Andreas _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
