[IGSTK-Users] Observe... methods generated by EventTransductionMacros

Luis Ibanez luis.ibanez at kitware.com
Fri Oct 5 15:37:04 EDT 2007


Hi Vincent,

Having the Observe___() method using only the Input (as currently
done in two of the transduction macros) may do the trick.

I'm trying to imagine a situation in which we may need to observe
two different Event types and need to map them to the same input,
... I guess that if such a case happens we can simply define two
different inputs, one associated to each one of the events.

I would slightly prefer this first solution, to the second one,
because in this first solution we enforce the naming of the methods
and make it consistent, while in the second option developers may
easily misname methods, however this it is not a strong preference
either...


   Regards,


      Luis




------------------------
Vincent Gratsac wrote:
> Hi Luis,
> 
> Thank you for your reply, I better understand the problem now.
> 
> I can see two solutions :
> 
>    - The first one would be to simply use the name of the input to 
> generate Observe method name in all EventTransduction macro. This only 
> includes to change the igstkEventTransductionMacro. I don't know what 
> you think about this.
> 
>    - The other solution would be to do like you described as the third 
> approach. That is to say, to add a third argument which would be the 
> name of the Observe method.
> 
> So my point of view is that if it is not possible or not good to use the 
> first solution, then the second one would be the best.
> 
> Thank you and have a nice day,
> 
> Vincent
> 
> 
> Luis Ibanez a écrit :
> 
>>
>> Hi Vincent,
>>
>> Thanks for pointing this out.
>>
>> We have created a bug report for this issue:
>> http://public.kitware.com/Bug/view.php?id=5826
>>
>> Although it is mostly a matter of coding style, you are
>> right regarding the inconsistency of the method naming.
>>
>> The challenge to fix it seems to be that there are situations
>> in which a class needs to listen to the same events from different
>> objects, and for each one, we need to generate a different input.
>>
>>
>> Strictly speaking the Observe method should probably
>> be named after the combination of:
>>
>>          event + input + observedObject
>>
>> However at that point, the name will be so long that we should probably
>> rather consider having an extra parameter in the macro and use it for
>> customizing the name of the Observe method.
>>
>> Consider for example the usage of the macros in the method"
>>
>> void
>> MR3DImageToUS3DImageRegistration::RequestCalculateRegistration()
>>
>>
>>   this->ObserveUSImageTransformInput(this->m_USFixedImage);
>>   this->ObserveMRImageTransformInput(this->m_MRMovingImage);
>>
>> Where the methods were created by the following Transduction
>> macros in the header:
>>
>>  igstkLoadedEventTransductionMacro( TransformModifiedEvent,
>>                                     MRImageTransformInput, Transform );
>>  igstkLoadedEventTransductionMacro( TransformModifiedEvent ,
>>                                     USImageTransformInput, Transform );
>>
>>
>> As you pointed out, we should have used the "Event" as the suffix of the
>> method name, but.... in this case we will have created two methods with
>> the same name.
>>
>> A second approach chould have been to use as name of the method the
>> combination:
>>
>>       Observe##event##input
>>
>> The will lead to a method called:
>>
>>     this->ObserveTransformModifiedEventUSImageTransformInput()
>>
>>
>> where the naming can easly go out of hand....
>>
>> Granted, we use that naming method for
>>
>>  *  the member variable of the observer itself
>>  *  the callback
>>
>> but the application developer doesn't have to deal with this
>> member variable nor the callback at all.
>>
>>
>> The third suggested option is to have a third argument in
>> the transduction macro and use it as the Observe method.
>>
>> For example
>>
>>  igstkLoadedEventTransductionMacro( TransformModifiedEvent,
>>                                     MRImageTransformInput,
>>                                     ObserverMRImageTransform,
>>                                     Transform );
>>
>>  igstkLoadedEventTransductionMacro( TransformModifiedEvent ,
>>                                     USImageTransformInput,
>>                                     ObserverMRImageTransform,
>>                                     Transform );
>>
>> that will be used as:
>>
>>   this->ObserveUSImageTransform(this->m_USFixedImage);
>>   this->ObserveMRImageTransform(this->m_MRMovingImage);
>>
>>
>> This last approach gives a bit more of flexibility...
>>
>>
>>
>>    Please let us know what you think,
>>
>>
>>
>>       Thanks
>>
>>
>>         Luis
>>
>>
>>
>>
>> --------------------------
>> Vincent Gratsac wrote:
>>
>>>
>>> Hi all,
>>>
>>> I noticed something strange in the following macros :
>>>
>>> igstkEventTransductionMacro ( event,  input  )
>>> igstkLoadedEventTransductionMacro ( event,  input  )
>>> igstkLoadedObjectEventTransductionMacro ( event,  input  )
>>>
>>> In fact, generated "Observe..." public methods are completed with the 
>>> #event name in the first macro, and with the #input name with the two 
>>> last ones.
>>>
>>> public:  void Observe##event(const ::itk::Object * object )
>>>
>>> public:  void Observe##input(const ::itk::Object * object )
>>>
>>> Is this difference normal or is this a bug ? Note that it is not a 
>>> problem for me... I just want to underline something that can be a 
>>> little error.
>>>
>>> Thank you and have a nice day !
>>>
> 
> 



More information about the IGSTK-Users mailing list