[IGSTK-Developers] Re: adding a method into state machine

[David Gobbi]

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
>>>
>>>
>>>
>>
>>
>
>