[Insight-developers] InvokeEvent / Observer / Command

[Brad King]

Luis,

Will and I looked over this solution briefly, and it looks fine to
us.  It sounds like you already have it implemented.  Go ahead and check
in the changes, and I will add the const smart-pointer support using the
mutable reference count approach.

-Brad


On Sat, 20 Jan 2001, Luis Ibanez wrote:

> Hi,
> 
> 
> There is another easy alternative to get around 
> the 'const' problem with the Command::Execute()
> method.
> 
> The option is to define in the itk::Command class,
> two Execute() methods, one with a normal pointer to
> LigthObject and the other with a const pointer, as:
> 
> Command::Execute(       LightObject * , Event e ) = 0;
> Command::Execute( const LightObject * , Event e ) = 0;
> 
> 
> Then, in SubjectImplementation class create an 
> additional InvokeEvent method, that receives a const
> pointer to Light object, like:
> 
> SubjectImplementation::InvokeEvent( Event e, const LightObject * ) 
> {
>   // with the same body that the non-const InvokeEvent method
> }
> 
> 
> and finally in LightObject add a const InvokeEvent() method,
> 
> 
> LightObject::InvokeEvent( Event e ) const
> {
>   // the same body as the non-const InvokeEvent method
> }
> 
> 
> 
> In this way, when a const LightObject calls its InvokeEvent()
> method, the const version of the method will be selected.
> This version uses in its body the (const *) version of the
> SubjectImplementation::InvokeEvent() method, and this one
> will call the version of the Command::Execute() method that
> receives a pointer to const LightObject.
> 
> This seems to be better that the previous suggestion
> of creating a PassiveCommand / ActiveCommand pair, 
> and having two separate list of observers in the 
> SubjectImplementation class.
> 
> One advantage of this option is that the current hierarchy 
> of Command's can be keept (with the only addition of the
> Execute( const LightObject *, Event ) method in the
> classes that derive from itk::Command.
> 
> 
> This hierarchy actually looks like:
> 
>  
>     +-------------+
>     | LightObject |
>     +-------------+
>            | (has one)
>            V
>   +---------------------+ (points to many) +--------+
>   |SubjectImplementation|----------------->|Observer|
>   +---------------------+                  +--------+
>                                                 | (has one)
>                                                 V
>                                            +---------+
>                                            | Command |
>                                            +---------+
>                                                 |
>                                                 |
>                                +----------------+
>                                |
>                                | (derivation)
>                                |
>          +---------------------+---------------------+
>          |                     |                     |
>          V                     V                     V
>  +---------------+  +---------------------+  +---------------+
>  | MemberCommand |  | SimpleMemberCommand |  | CStyleCommand |
>  +---------------+  +---------------------+  +---------------+
>      
> 
> 
> The only class that need more modifications with this option,
> is CStyleCommand, which has a pointer to a normal C function
> that receives a (LightObject *, Event).  It will need now a
> second pointer to a C function that receives (const LightObject *,
> Event ). Its second Execute() method will call this new pointer to
> function  while the original Execute method will still use the 
> original pointer to C function.
> 
> These modification compile fine, and as far as I've tested
> it seems to run ok.
> 
> 
> 
> 
> Luis
> 
> 
> 
>