>>>Actually finding things in project manager is the only reason against having each thing in its own prg, because it would clutter the pjx. On the last few projects I did the number of free-floating functions was reduced drastically by grouping them into objects (by purpose), which are then instantiated as singletons - but the function calls are still in too many places in code, so there's usually one big prg with just stubs - something like
>>>
>>>function GetAppRootPath()
>>>return app.oPaths.approot
>>>
>>>So instead of having getAppRootPath.prg, getAppLaunchPath.prg, getUserDocsPath.prg, getTempPath.prg, etc, there is just libPaths.prg, etc etc. The remainder are the few dozen functions which didn't have a natural global object which would host them.
>>
>>Disagree totally ;-)
>>In my book such access paths should be shortened/automated, yes, but not via function or method call but by compiler constants -
>>skip the overhead of calling in the next stack level (yes, I know without parameters calling is much faster...)
>>If you keep all constants in upper case, whenever a constant shouts repeatedly in the code I am working on, I automatically cache the (possibly reached via long and convoluted way) access result in a local var ;-)
>
>That sounds interesting. Can you give a sample? I made a snippet factory. The amount of code involved seemed it would be slow, but using it and executing the result was far faster than calling a UDF or Method.
>
>Pseudo Example:
>
>definition: datevar2 - datevar1
>
>preparation:
>datesnippet.datevar2 = "date2fieldname"
>datesnippet.datevar1 = "date1fieldname"
>
>lcDateSnippet=datesnippet.getsnippet
>
>text to lcCmd
>select < < m.lcDateSnippet > > as datedifference from mytable into cursor test
>endtext
>&lcCmd
>
>Attempting to execute
>
>select oObject.DateDifference(date2fieldname, date1fieldname)
>
>or
>
>select DateDIfference(date2fieldname, date1fieldname)
>
>Were slower than generating the textual formula and executing the SQL with macro.

Of course - In SQL context the macro is compiled/executed only once, whereas function/method calls typically are called (including typical stack gymnastics) 1 + where-filtered reccount in your example. Similar to eval() in SQL being most of the times slower than macros, whereas in normal looped execution eval() is faster. Even worse would be calling a function and giving it the database columns as parameters, as parameter passing in vfp is more costly compared to other languages, even interpreted/dynamcally typed ones like JS or Python. Fox probably showing its age ;-)

Another way to put it is macros in SQL statements are the only possible inlining perf enhancement in vfp ;-))