>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!

Just to be clear, because I'm not sure we are talking about same thing:

If you create Behavior using AddObject, you can do This.Behavior = .NULL. and let the container to destroy the Behavior object. But in this case you can't be sure that the container will try to destroy the parent before the Behavior.

If you create Behavior using CreateObject, you can't do This.Behavior = .NULL. You must call the destroy/release for the Behavior.

Isn't it?

Of course, the Behavior will never try to destroy his parent.

>> >> 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.

Nowhere! :) I thought we are still talking here about AddObject... :)

>> 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!

Exactly.

>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 ???????

No. All classes have a Behavior property. But that doesn't mean there's only one Behavior object for the whole app at runtime. The whole idea is that we can have A LOT of Behavior classes. And, of course, we can instantiate and use them as we want at runtime. It's extremly flexible and it can be done at runtime. 

We can have Behaviors to modify only the Click method, only MouseMove method, etc. Or Behaviors to modify security rights/levels. Or anything else we can imagine. And we can play with them as we want at RUNTIME. You don't need to subclass everytime you need to change a small thing in a class and to have an enormous pyramide/hierarchy of classes. It's enough to hook some Behaviors.

>> 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...

It's what I was saying a little higher.

>Thanks Vlad.  It _is_ a pleasure to discuss this with you.

For me too. BTW, I just reviewed Steven Black's presentation notes from FoxTeach and he is using the name "Decorator" for Behaviors. I believe his original name is better. Because it's exactly like you would decorate things. You can decorate something that is already decorated, and so on.

See you,
Vlad