>>>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.
>
>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
Thanks Thomas,
the class library suggestion i will pursue. but being a PhysED major the suggestion of C language is beyond me. I have a some experience in C# perhaps that might be a viable substitute?
Barry Taft
i am only worried in the short term. once there is a problem, the solution usually presents itself.