>>>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.

Again - where. Where will I use it? The place to put it depends a lot on that. For instance, in several branches of the app I have to handle external files, for different reasons (some are just general reading stuff for users - various manuals and howtos; some are users' own files; third category are report files - say frx/frt, and various little config files and sidekicks also come into play). Now there are several classes which keep different parts of operation together - one is the pathing, responsible for file locations. The other is the general file class (copy, move, check for locked), then the zipper class (reports go with the query, so to make it transportable with the database or packaged) etc etc. IOW the form which handles a query doesn't contain the code to zip the report, it just says this.oBiz.Save(queryPK); oBiz has its own instance of file handler and zipper. In some cases file handler is instantiated without the zipper etc etc.

So yes, grouping by purpose or by usage. The tricky part is to know in advance when a piece will be used in other places, which usually doesn't seem so while you build it. It gradually becomes popular - and then if you didn't foresee it, you may have some functionality in wrong places. IMO, refactor it while it's small.

>Grouping modules functionally makes sense to me.
>I don't expect to find accounts payable functions mixed with cash receipts functions.

Depends on your accountant :). They may actually be the same with just a couple of parameters different, if you developed here. Accounting is a foreign land.

>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

Yes, and then you wish there was some divine inspiration to help you pick the right name for it, so you'll both be able to know what it does when you see it, and to remember it when you need it.