>>>>Mike, do you mean that you'd rather have a function in a .prg than in the form that called the function?
>>>
>>>It would depend on the nature and usage of the function. If it's not used anywhere else, that function naturally belongs into a method of that form. Even better, in my way of doing things, it's a function in the bizobject used in that form - and generally it's a bizSomething.prg.
>>>
>>>And how exactly did we go back to the original question of the OOP paradigm? The famous "where does the code go?".
>>
>>To these tenets "Inheritance, encapsulation, abstraction, and polymorphism" I'd add - "usability."
>>If I can't find, I can't use it.
>>Grouping modules functionally makes sense to me.
>>I don't expect to find accounts payable functions mixed with cash receipts functions.
>>Putting them in the form, or the class, the folder, or the procedure file that particularizes (love that word) these functions - all performance considerations being equal - makes good sense to me
>
>That's why I don't group anything together at all. Look at it this way. When you issue the following command: ?Date(). Did you first have to
>
>SET PROCEDURE TO FoxPro.NativeFunctions.DateFunctions.JustBecauseSomeoneThinksAggregationisUseful
>
>Name pieces of code appropriately. Put them where they are immediately accessible - without digging through one or more procedure "libraries". That makes them immediately useful and applicable to a wider range of applications. The project manager will aggregate them - at the appropriate time - and you don't have to do anything except remember the function name. It's like being able to reach out and grab a screwdriver from midair, instead of first having to ask - where did I put that screwdriver?

>> where did I put that screwdriver?

Yes, that's a common question.

Your points are valid, but I suggest that there are limits to any good idea and I'm wonder what they are in this case.
I'm not being argumentative, I'm trying to find your idea of a good limit.
Let me pose it this way:
I handle development for several clients.
For any one client I might have some VFP code, some .NET code, some HTML, some SQL and some PHP.
Within each language I might have several applications that are logically and functionally discrete.
So
Should keep all my code for all clients together or should I segregate by client?
Within a client, should I keep my VFP code with my .NET code or should I segregate it?
Within a client and a language I might have a Payroll application and a Billing application that use common base class libraries but are otherwise discrete. Should they all be together?

I won't go on.. you see my point.
What do you suggest would be a good way to organize things?