[Insight-developers] InvokeEvent / Observer / Command

[Luis Ibanez]

Hi Brad,

I checked in the changes to itkCommand and itkLightObject.

In CStyleCommand a second pointer to function was added.
Its name is not very original now:    "FunctionPointer2"
and its member variable is   "m_Callback2"   ...
Please feel free to change them if you find a better
descriptive name.


Thanks,

Luis


Brad King wrote:

> 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
> >
> >
> >
> >
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers@public.kitware.com
> http://public.kitware.com/mailman/listinfo/insight-developers