>>Hi,
>>
>>I am looking for suggestions to the following decision I have to make:
>>
>>I have a public object (oApp) already working in the application. Now I need to add an object (also public) that will have a bunch of methods that I want to have available in every place of the application. I can add this new object to the application as a public object or I can add it as a property of the already existing one (oApp). For example:
>>
>>

>>*-- Choice 1:
>>public oCommon
>>oCommon = newobject("common_functions","my_commonlib.vcx")
>>
>>*-- Choice 2:
>>*-- public object oApp already exist.
>>oApp.oCommon = newobject("common_functions","my_commonlib.vcx")
>>

>>
>>What is a better approach in terms of memory management?
>>
>>Thank you.
>
>I'm not sure which is better in terms of memory management. In terms of OOP, neither is appropriate IMO. You're trying to emulate the old dBASE procedure library. The correct way to do this IMO is to build the class library into your application and then instantiate objects and call methods as needed.
>
>If you really want SET PROCEDURE behavior, that's still available to you, no need to use a class or object at all.

I think you either misunderstood my intent or I didnt explain it well. I don't want the SET PROCEDURE behavior with a set of functions. The main reason is the VFP functions can return only one value. I know you can return an array but it is a kludge. I prefer to have a set of methods of a globally available object. The advantage with methods is that multiple values can be returned to the calling procedure, using object properties.