>>>I think VFP objects inherit from Control or something like that - but the other part is the problem, we can't subclass from there. The search for the lightest base class started very early - Line was the one, IIRC.
>>>
>>
>>VFP objects do not inherit from Control or any other common ancestor. There are a dozen or so second tier base classes, which is as low as it goes. The absence of a "mother of all classes" is the reason we had to resort to kludges like deriving from Line just because it's lightweight. I write a non-visual class to model some real world process and call it a Line? Jeez Louise.
>
>Louise is a heathen :), and you can call it whatever you want.
>
>I still think there is such a class in VFP, somewhere inside, and my complaint is that it wasn't exposed to us to subclass at will. Either way, we don't have it, and I dislike it just as you do. Doesn't matter whether it exists or not behind that closed door, we can't play with it.
>
>>>>See http://www.dofactory.com/Patterns/PatternDecorator.aspx
>>>
>>>Yes, that would work - as long as there are equivalents to pemstatus(), getpem() and such, it could be made to work on a generic object.
>>
>>Sigh -- you are not getting this. You keep thinking action-object instead of object-action. I know you are smart enough to get away with it but you are really swimming hard against the current.
>
>In the object.action() paradigm, why can't my objects act on other objects? I'm doing a oDecorator.Lipstick(oAnyObjectRef). I am not keen on making objects which are in a feud and won't talk to each other. I want them to be able to have one comb hair and fasten the zipper on the other, simply because it's far less code to have oComber.Comb(oAny), than to teach every class how to comb its own hair.

But not every class has hair, or the need to comb it. An OO design would have a class called Hair which includes a method called Comb(). That way any object of type Hair would be able to call this method, as would any object of a type derived from the Hair class. Write it once, done. Why should the Comb() method have to waste time checking object types? "Is the passed parameter a TextBox? Nope, move on. Is it a ComboBox? Nope, move on." Etc. until finally we arrive at the code that deals with type Hair.

I don't think either of us has convinced the other but this has been an interesting discussion. See you tomorrow....