Re: [boost] Re: Re: Re: Finite state machine requirements

From: David Cattarin (ditto_at_[hidden])
Date: 2002-09-11 13:35:25

Andreas Huber wrote:

>>Yes, my system is type safe, but I don't define individual types for
>>each event, transition, and state. Events are a simple class with a
>>string identifier and a property map to contain the parameters. It is
>>simple, easy, and doesn't use much memory.
>>    
>>
>
>By type-safe I meant compile-time detection of type mismatches. I guess you
>can detect type-mismatches only at runtime. Again our fundamental
>disagreement...
>

Andreas, I've said several times that I'm not against compile-time 
detection of errors. I am against using that as the *only* way of 
constructing state machines.

>>BTW, what is gained by typing each event? If your events are generated
>>interanally--mine are not--then you can catch, at compile-time, bad
>>events. I get messages from the network which are filtered in order to
>>determine the kind of event. A simple string identifier seems sufficient
>>to me.
>>    
>>
>
>Even if you receive events over the network, I believe typing your events
>still adds a lot to the safety of your system:
>- There's _one_ place that's concerned with detecting bad events, i.e. the
>object deserialization mechanism.
>

Not true. You are assuming that all this code is collocated. It is not. 
As I've said, I use a filtering mechanism to determine events. It is 
much simple to construct string identified events in this case.

>- The whole rest of your application works with and benefits from typed
>data.
>

You've assumed a lot about the structure of my system.

>Given that the string identifier of an event is correct then I guess you
>only detect in the event-handler that you received an event with some
>parameter having the wrong type or missing altogether. 
>

Only partly true.

>Don't you think it's
>better to catch such problems at compile-time? How do you handle such a
>situation?
>

Andreas, in the past two years, we've only had a handful of problems 
associated with bad events, or bad transitions. Perhaps compile-time 
checking would have caught that. This particular framework that I've 
built requires that the state machine and events be configured 
dynamically. It *can't* be set-up for compile time since it would not be 
useful for what we want to achieve.

If you can't see any use for such configurations, then go ahead and make 
a compile-time only system. I'm sure it will be useful. But, you should 
recognize that there are classes of applications where it is not.

I'm going to be away for the next while, so I won't have time to talk 
about this.
Dave