I think on a theorhetical level, it is a question of language design. C# ( where I am painfully feeling my very beginner way ) for example is supposed to be one of the oopiest of languages - everything is an object. The STR() function we would use is incarnated as a .Tostring method of the integer object. Kind of cool when you think about it.


>Hi Craig,
>That actually makes sense to me. But it leaves a few questions.
>
>To borrow a quote from Marcia Akins.
>Does OOP demand that we "crack walnuts with a sledge hammer" rather than use one of those functions that you have to throw data at?
>
>Example:
>It appears that there is no 'simple' way to replace wParent() and wExist() in OOP. It's possible to design an 'window tracking system' to get at that information, but it's overkill unless you need that system for other things.
>IOW: Designing a 'window tracking system' for the SOLE purpose of replacing wParent() seems to violate a more basic principle; "KISS".
>
>
>
>>The way it was explained to me is that OOP is doing things upside down. Instead of taking a function and throwing data at it, you take data (or an object) and throw a function at it. In otherwords, an object should be responsible for itself. For example,
>>
>>? WVISIBLE("MyForm") as opposed to ? MyForm.Visible
>>
>>>I've been told that w***() functions (wontop(), wparent(), etc) are not OOP, but I don't understand why.
>>>
>>>It seems to me that the arguments that I've heard could be applied to just about any function that existed before OOP.
>>>ie: "srows()" existed before OOP, so does that make it non-OOP?
>>>How is that different than "wparent()"?
>>>
>>>What am I missing?
>>>
>>>TIA