[IGSTK-Developers] Get method possibilities

[Luis Ibanez]

Hi David,


The unsafe Get() methods were modified according
to your suggestion.


The usage now looks like:



   typedef ReaderType::DICOMInformationType TType;

   if( reader->FileSuccessfullyRead() )
     {
     TType  patientName = reader->GetPatientName();
     TType  patientID   = reader->GetPatientID();
     TType  modality    = reader->GetModality();

     std::cout << "Patient Name = " << patientName << std::endl;
     std::cout << "Patient ID = "   << patientID << std::endl;
     std::cout << "Modality = "     << modality << std::endl;
     }
   else
     {
     std::cout << "The file was not successfully read" << std::endl;
     }



Application developers are now responsible for invoking
and checking the return value of the Pre-Condition method

                  "FileSuccessfullyRead()"

before they attempt to use the values returned by the
unsafe Get() methods.


The modifications have been committed to the Sandbox and
will be included in the soon-to-be:   Release 6.


Please let us know if there are any other changes that
we can make in order to make the experience of writing
IGSTK application more pleasant and convenient for
application developers.



   Thanks


      Luis



------------------
David Gobbi wrote:
> Hi Luis,
> 
> My preference in this case is #1.
> 
> I actually think that exceptions are the
> better solution, but I don't want to see
> any exceptions added just before
> a release.
> 
> - David
> 
> Luis Ibanez wrote:
> 
>>
>> Hi David,
>>
>> Thanks for posting the alternative options
>> for implementing the unsafe Get() methods.
>>
>> -- 
>>
>> What would be your preference between the
>> options:
>>
>>
>>     1) Adding FileSuccessfullyRead()
>>        removing the booleans and adding
>>        the [const std::strings &] on return.
>>
>> or
>>
>>
>>     3) Throwing Exceptions when the
>>        values are not available.
>>
>>
>>
>> [ Option (2) is the current one,
>>   so I would guess it is not int the list.
>>   The purpose of having the boolean to be
>>   returned by the same Get method was to
>>   ensure that the precondition and the action
>>   were performed as an atomic operation, but
>>   I agree with you in that we should not use
>>   any code that resembles FORTRAN. ]
>>
>>
>> -- 
>>
>> Given that the Get() methods are now tagged and
>> recorded in the Logger, we could easily go with
>> any of the three proposed alternatives, since
>> none of those is quite fit for a State Machine
>> architecture anyways.
>>
>>
>> We just need to pick up the one that will reduce
>> the developer's effort to a bare minimum, make
>> them feel more comfortable, and provide them with
>> the maximum of flexibility.
>>
>>
>> Please let us know what would be your preference
>> so we can make these changes today before moving
>> the code to the main IGSTK library.
>>
>>
>>   Thanks
>>
>>
>>      Luis
>>
>>
>> -------------------
>> David Gobbi wrote:
>>
>>> Hi All,
>>>
>>> The ImageReader Get methods that were just added to CVS are a
>>> bit clunkier than I would like,  due to the boolean return value.  In
>>> VTK and ITK, the methods would return the string (or a const
>>> reference to the string) and forgo the boolean return value.
>>>
>>> Typical VTK/ITK code looks like this:
>>>
>>> if (reader->FileSuccessfullyRead())
>>> {
>>> std::string   patientName = reader->GetPatientName();
>>> std::string   patientID = reader->GetPatientID();
>>> std::string   modality = reader->GetModality();
>>>
>>> .. plus additional code to process the information
>>> }
>>> ... at this point in the code, the patientName, patientID, and modality
>>>   variables are no longer in scope, so there is no danger of them being
>>>   used if the file hasn't been read yet.
>>>
>>> With the methods that were just added (with the boolean return value),
>>> the code will look like this:
>>>
>>> std::string patientName;
>>> if (reader->GetPatientName(patientName))
>>>  {
>>>   ... use the patient name
>>>  }
>>> std::string patientID;
>>> if (reader->GetPatientID(patientID))
>>>  {
>>>  ... use the patient ID
>>>  }
>>> ... and so on for modality
>>>
>>> ... at this point in the code, the "patientName", "patientID", and 
>>> "modality"
>>>   variables are all still in scope, even if the Get() methods 
>>> failed.  This sort
>>>   of a programming pattern reminds me of FORTRAN.
>>>
>>> Just my two cents.
>>>
>>> - David
>>>
>>> P.S. I can't resist adding an example that uses exceptions:
>>>
>>> try
>>>   {
>>>   std::string   patientName = reader->RequestPatientName();
>>>   std::string   patientID = reader->RequestPatientID();
>>>   std::string   modality = reader->RequestModality();
>>>   .. plus additional code to use the information, not executed if an 
>>> exception occurs
>>>   }
>>>  catch (InvalidRequest)
>>>   {
>>>   ... send debug info to logger
>>>   }
>>>
>>> _______________________________________________
>>> IGSTK-Developers mailing list
>>> IGSTK-Developers at public.kitware.com
>>> http://public.kitware.com/cgi-bin/mailman/listinfo/igstk-developers
>>>
>>>
>>
>>
> 
> 
>