> > >All it takes is Parent.Behaviour= .null. in the Parent.Destroy() method, > >and repeat this in each baseclass that you want to own a Behaviour > >object. > > Are you sure that Parent will be always before Behavior in the destroy > sequence? > Yes. Since destroy is a method of Parent destroying Behaviour, Behaviour should of course not try to destroy Parent, but I do not see why that would be needed. Patricide it's called! > >> It means that each time the container will scan its collection of > objects > >> (Refresh, etc), it will process some extra objects. And I don't see any > use > >> of it. It will only slow down some actions. > > > >Yes but if you _want_ the functionality of Behaviour, you cannot add > >without _some_ code, can you? > > I still don't see what advantage would it be to link Behavior objects to > the container. I fail to see where the container comes in here if you instantiate Behavior with createobject. > > >> The real power of these Behavior classes/objects is that you can > chain/hook > >> them. > > > >So what is it that you _do_ advocate? > > All classes can have a Behavior properties. Behavior classes will have it > also. > > Lets say we want to modify the Click method using the Behavior. It will > look like this: >

> if type( "This.Behavior.Name") = "C"

So Behavior _is_ owned by Parent (This) in HasA relation!

>    *-- Yes, there is a Behavior set for this object. Use it.
>    This.Behavior.Click()
> endif
> *--Here goes the usual code for this Click method.
>

> > So, now we have a "hook" to te Click method. OK! Now I see what a hook is. Thanks. We can modify the Click method > at runtime by using/changing the Behaviors. Call me a vegetable, but again, this I do not understand. But don't forget that Behavior > class has the same hook in its Click method. Recursion ??????? So, we can do the same thing > for the Behavior object and for Behavior's Behavior object, and so on. > > What's very good, it's that all these can be done at runtime. It's like you > would modify the hierarchy of your classes at runtime! > Sorry, but here you are loosing me again... > Please note that in the previous sample Click is prehooked. It can be also > posthooked if the hook is in the end of the method. But NEVER do both for > the same method. > Yes. This is obvious. Thanks Vlad. It _is_ a pleasure to discuss this with you. Marc