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

[Luis Ibanez]

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