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

You can if the pointer to the behavior object is a property of the
parent! I thought that we agree to this. You have the best of both
worlds this way!

When the property is to .null., or to any other value for that matter
the child object is destroyed, in any case it will not prevent the
parent to disintegrate.
>
>>> >> 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... :)

That settles that then :)
>
>>> 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.
>
From this I conclude that your Behaviour is not pointed to by a
 property!  You 'instantiate' kind of when you need it.  In my scheme
Behaviour functionality is added at base class level, so you know 
it's there, and the maintenance can be inherited...

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

I fail to see at this stage why I would want to 'modify' these
 methods, and at runtime, meaning that the response to an event
would be different depending on a particular state of the program.
Interesting, but not high on my list of priorities (the dyno in me
 probably! :)).

>
>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.
>
... and he got that from Pattern theory I think.   What's in a
name ... So let's call it the decorator then.

Regards,

Marc


If things have the tendency to go your way, do not worry.  It won't last.  Jules Renard.