> > >I have found out that you can work around this: if you define a > >property in the parent object and issue ... > > > >this.Property= createObject('BehaviourClass') > > Of course. This is what I was saying: CreateObject() instead of > AddObject(). > > >It has all the advantages of the addobject method, without the > >disadvantage of the parent class having to be a container. > > Exactly. > > >> 1. You will have the following relations between objects (triangle of > >> relations): > >> Container->Behavior > >> Container->AnObject > >> AnObject->Behavior > > > >This, to be honest, I do not understand. > > It means: > The container ownes the Behavior > The container ownes the AnObject > The AnObject ownes the Behavior > > When you have a situation like this, VFP 3.0 will fail to destroy these > objects. because: > If the AnObject is to be destroyed first: it can't do it because AnObject > points to Behavior, which is not destroyed yet. > If the Behavior is to be destroyed first: it can't do it because AnObject > points to Behavior and AnObject is not destroyed yet. > I've heard that VFP 5.0 works better, but I had no time to test it. > > >> This means that you must write additional code to be able to destroy > these > >> obects correctly. > > > >You do this in the base classes no? > > Yes, you can do it, but it's an useless overwork. > 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. > > > >> 2. The container will be loaded with some (usually) non-visual objects. > > > >So ? > > 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? > > >> 3. It reduces the generality <snip> > > > >The price to pay to use composition i.o. inheritance ... > > Yes. But if you don't need composition, why use it? :) > > >Yes. But this problem would be solved (and others probably created) if > >we had multiple inheritance, i.e. that a class could inherit from > >multiple classes (i.o.w., multiple superclasses). > > This is true. But multiple inheritance has its big pitfalls as well. > > >> >This way all the base classes can share methods _and_ properties ... > or > >> >am I missing something? > >> > > > >Well all the properties that are owned by the behaviour class are > >accessible by the objects of classes that own this behaviour class. Or > >is something else meant by 'sharing properties'? > > Yes. The problem is you can't use these properties directly (e.g. > Object.Property). And you can't chain/hook properties directly. > chain/hook ??? Quid est? The syntax would be Object.Behaviour.Property. > The real power of these Behavior classes/objects is that you can chain/hook > them. > So what is it that you _do_ advocate? > Have a nice weekend, > Vlad Same to you Marc