>>>Are tricks also for "Set Procedure To"?
>>
>>I hate procedure files and when possible, eliminate them. I wrote about that: http://www.tomorrowssolutionsllc.com/Articles/Splitting%20a%20Procedure%20File.PDF
>>
>agreeing to most, as procedure files have a FoxPro, not OOP smell.
>
>Speed benefit of functions over methods exists, but in most cases is not relevant, so moving into classlibs often makes sense - but into smaller classlibs, grouped according to usage or topic.
>

In my view, most procedure files should be broken into separate PRGs. Sure, if you have a group of functions that operate on shared data, a class is the way to go. But my experience is that procedure files are just piles of functions that are unrelated to each other except broadly. Make them PRGs.

Tamar



>Sometimes it does make sense to keep a "topic" function based, for instance if some of the functions are used so often and have bad runtime characteristics that you need to port a few of them to C-fll
>Example could be function library to create or work with CSV strings
>
>A few simple rules make such proc libs less painful:
>create a function naming schema which identifies the lib the function lives in: csv_whateverfunction()
>create method signatures where order of first parameters is consistent
>
>From then on you can code specific hurt point in C if measuring makes it clear a function bogs down the program.
>
>But even for such purposes sometimes it *might* be beneficial to create a classlib first:
>If "csv" includes working with separators other than comma (think semicolon for Excel or Tabs), the separator should be defined as a property of the classlib to avoid passing it in each method or function call.
>
>When working on C replacement, such Properties are best NOT accessed in vfp variable space, but copied via access/assign into corresponding C memory space: set once, speed up in every call not needing the parameter.
>
>YMMV
>thomas