[IGSTK-Developers] Re: adding a method into state machine
Hee-su Kim
hkim at isis.imac.georgetown.edu
Tue Sep 20 09:04:02 EDT 2005
Hi Luis, David,
Okay, I'll remove the new method.
I asked you because I wasn't sure.
I thought it might be helpful when we have multiple ways of branches in a
state machine.
Hee-Su
----- Original Message -----
From: "Luis Ibanez" <luis.ibanez at kitware.com>
To: "Hee-su Kim" <hkim at isis.imac.georgetown.edu>
Cc: "David Gobbi" <dgobbi at atamai.com>; "IGSTK-developers"
<igstk-developers at public.kitware.com>
Sent: Monday, September 19, 2005 6:52 PM
Subject: Re: adding a method into state machine
>
> Hi Hee-Su,
>
> I agree with David,
>
> There doesn't seem to be an advantage in moving the selection
> of the input to the state machine; unless this is code that
> we are going to find more and more often...
>
> In how many places would you anticipate to take advantage
> of this new function at this point ?
>
>
>
> Luis
>
>
> ------------------
> David Gobbi wrote:
>> Hi Hee-Su,
>>
>> In my email I said that map is a _good_ idea, I didn't have any
>> complaints about it.
>> My comment was that I am not sure if you need to define a new state
>> machine method.
>>
>> - David
>>
>> Hee-su Kim wrote:
>>
>>
>>>Hi David,
>>>
>>>I'm using a map to avoid using if-statements which can decrease coverage.
>>>
>>>DefaultInput plays a role of safeguard to prevent crash when an
>>>unexpected value was returned.
>>>
>>>In the case of PushInputBoolean, the condition can have only one of
>>>two values. true or false. And we specified two inputs.
>>>
>>>However, an integer variable can have one of a lot of numbers.
>>>The application might crash if a return value was not in the map.
>>>
>>>That case can happen when:
>>>* a developer added a new return value (new error code) but didn't add
>>>a new map entry.
>>>* developer's mistyping.
>>>* a logical bug.
>>>* etc.
>>>
>>>If an application crashes in development stage and then fix bugs, it
>>>would be not bad.
>>>
>>>If an application crashes during operation, it can be critical.
>>>
>>>We could use UnexpectedInput or FailureInput as DefaultInput with
>>>logging "ERROR: Unexpected value was passed to be translated to a
>>>input. Please make sure the value is correct. Value: ###".
>>>
>>>Hee-Su
>>>
>>>----- Original Message ----- From: "David Gobbi" <dgobbi at atamai.com>
>>>To: "Hee-su Kim" <hkim at isis.imac.georgetown.edu>
>>>Cc: "Luis Ibanez" <luis.ibanez at kitware.com>; "IGSTK-developers"
>>><igstk-developers at public.kitware.com>
>>>Sent: Monday, September 19, 2005 3:10 PM
>>>Subject: Re: adding a method into state machine
>>>
>>>
>>>
>>>>Hi Hee-Su,
>>>>
>>>>I think it is a good idea to have a map to translate a return value
>>>>into a state machine input.
>>>>
>>>>I'm not sure if we need a new state machine method, though,
>>>>since the following code is already elegant and easy to understand:
>>>>
>>>>m_StateMachine.PushInput( myIntToInputMap[myIntValue] );
>>>>
>>>>The main reason I think that the above code is better, is that
>>>>in the case of Read and Write we know that only three return
>>>>values are possible, so there is no need for a "default" input.
>>>>
>>>>- David
>>>>
>>>>
>>>>Hee-su Kim wrote:
>>>>
>>>>
>>>>>Hi, guys,
>>>>>
>>>>>I'm trying to modify SerialCommunication::Write & Read to return
>>>>>values as David suggested.
>>>>>
>>>>>Write & Read methods return values such as SUCCESS, FAILURE, TIMEOUT.
>>>>>
>>>>>Because there are 3 result values, it can't be handled with
>>>>>PushInputBoolean().
>>>>>
>>>>>So, I'm considering to add the following method.
>>>>>
>>>>>It maps an integer value to an Input.
>>>>>
>>>>>How do you think about this?
>>>>>
>>>>>
>>>>>template<class TClass>
>>>>>void
>>>>>StateMachine< TClass >
>>>>>::PushInputMap( int condition, const map<int, const InputType>
>>>>>&conditionInputMap,
>>>>>const InputType & inputDefault )
>>>>>{
>>>>>const InputType *input = & inputDefault;
>>>>>
>>>>>if ( conditionInputMap.find(condition) != conditionInputMap.end() )
>>>>>{
>>>>>input = & conditionInputMap[condition];
>>>>>}
>>>>>
>>>>>m_QueuedInputs.push( input->GetIdentifier() );
>>>>>}
>>>>>
>>>>>Hee-Su
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>>
>>
>
>
More information about the IGSTK-Developers
mailing list