>>>>>>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?
>
>Absolutely everything should be together. It's only necessary to organize things virtually. I saw a system recently where they had a copy of the system per client. There was no obvious distinction between code for everyone versus code that was specific to a client. There was no source control to merge things either. It was messy. They used MaxFrame and despite my having worked with/for Drew and helping make MaxFrame - they "knew" better and would not listen.
>
>First and foremost create code that is universal. That is what frameworks are for. That is what the functions/commands in VFP are. Code is a blueprint. The distributed application is the product. Don't confuse these two. Runtime and design time are separate. Don't be overly concerned with having everything in a library because that means you can share it with another developer. That's not significant at runtime.
>
>Code is a blueprint - use tools to "package" them per client - thereby having one code base with tiny exceptions per client. You cannot safely have a method which differs per client - that's what subclassing is for. The project manager is not the best tool to manage modules across clients. All it really is good for is building an exe.
>
>I would definitely not segregate by language. Segregating/aggregating is a design time action. At runtime the pieces all come together regardless of the language as they should.
>
>Software is virtual - all source code is supposed to be divided into tiny pieces - atoms so to speak - and should be immediately accessible at runtime. If that was truly done, I could call for the screwdriver and it would appear - that is magical - that is powerful. It's more like a surgeon calling for a scalpel, instead of rummaging through drawers and shelves while the patient dies. Running around trying to figure out where things got put is wasteful and not required in software. I saw an electronics manufacturer prepare trays with parts for the workers and it made their assembly task really efficient.
>
>It's the computer's job to find and organize stuff - like a nurse. We're the surgeons, but the software tools are lacking or really expensive. Using the VFP toolbox, for example, you can have one or more collections of the client specific code/modules and not have to see the huge list of stuff in the project manager. I think the toolbox can also segregate/aggregate code virtually even if every thing is physically in one folder - certainly it can represent a single class from a class "library". That reminds me - the scx only contains a single screen. It's structure is the same as the vcx. The vcx does not only contain a single class.
>
>We really need some kind of CAD package to track all the parts as they are to be included in the exe (distributed). Physically aggregating things together only applies to the person that did the aggregating and only to physical objects. No one else can guess what the reason for aggregation was. If you build a car engine, you may have a ton of parts and tools, but in the end, the engine becomes its own entity. It most certainly does not contain any unused cylinders and a leftover wrench. That is engineering.
>
>Software should be more like 3D printing. Draw the model, compile (print) and you get the end product.

Good insights, Mike.
You've expanded my thinking.
Thanks