>>>Hi
>>>This isn't a problem. Rather, it's just a discussion of something I'm curious about VFP.
>>>
>>>As c# developers know, we can't write a method/procedure/function in c# outside of a class.
>>>But in VFP you can.
>>>
>>>So, I have a co-worker who saw my VFP code that wasn't rapped in a class. He asked why?
>>>I'm new to VFP, so I just said "because you can in VFP".
>>>;-)
>>
>>A class can have it's own datasession (if you set it -- we subclass our classes to have that).
>>
>>So if a separate datasession is desirable (to preserve data state, or to minimize cursor naming conflicts), that can be a big advantage. Properties that belong only to the methods of the class are also useful. Having instantiation code that is particular to the object can be useful.
>>
>>If it's just a matter of where to store functions and procs, however, a procedure prg is just as good.
>>
>
>As each method gets an imlicit this parameter passed, any method code not recurring to data on this (or own datasession) will be faster if coded as a function. At least at framework level coding (possibility to be called often or in a loop) this should be cared about, esp as vfp is not the fastest language when calling next stack level with many parameters compared to statically typed languages ;-)
>
>Also the gymnastics sometimes used by Java and C# to allow running code without the class being instantiated argue for function libraries in my book ;-)))

Edge conditions always but by definition seldom apply. And in most cases the call will be to a method in the class foranything with a large number of calls. As with all programming whether classes or prg libraries, the goal is to segregate functionalities into separate ecologies.

So after taking the above into account, the decision devolves to the major differences between the two approaches, I think along the lines I laid out.