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