From: Andreas Huber (spam2002_at_[hidden])
Date: 2002-09-11 08:44:01
> I understand (mostly) what is involved here but still struggle with the
> sheer quantity
> of framing/cruft/... required to implement a machine.
[ ... ]
I hear you! That is what I'm currently concerned with as well. Even if the
improvement suggested in my previous post is applied to the original
approach, the result can definitely not be learned in 10 minutes, even if
you are familiar with all the UML stuff. Joel de Guzman has just introduced
me to three people who apparently have been working on FSM frameworks with
interfaces similar to the one exposed by spirit (http://spirit.sf.net).
Maybe their approach has a nicer interface. We'll see.
> Wondered about the commitment to UML FSMs but I suppose that SDL cant
> really compete, in terms of who-is-using-what modeling techniques.
Well, I don't know anything about SDL (although some of the specs in my last
project were in SDL, IIRC). I simply think that the UML way to draw state
charts _and_ the UML state machine semantics are easiest to understand.
Moreover, it seems to be the standard which has gained the most widespread
[ ... ]
> My biggest
> dilemma with your FSM library is that I don't think it has these kind of
> goals (no
> library seems to BTW ;-) and its also quite difficult to divide the signal
> (i.e. FSM events) from the distributed nature of my problem space (e.g.
> transports and messaging systems).
I haven't had any exposure to your problem domain, so I guess I won't be of
much help here. Don't know whether this is one of your problems but all I
can say is that the proposed FSM framework does _not_ force you to make
events nested classes of your state machine class. So, the same event can be
shared between any number of state machines. Simply make the events globally
visible and you're almost done. However, passing events from one state
machine to another is a bit cumbersome at the moment but could easily be
made much more straightforward. Just let me know.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk