I think this depends on what kind of control you have over the called function. Possibly Rick has tight control over the called functions and if a called function changes an object, Rick would say the problem is in the called function. If a function for some reason might want to change a property's value, for use later on within that function, a local variable could be defined and used instead of the object's property. In other words, leave the copying of the object's components up to the called function instead of copying the whole object before the function is called.

Again though, I think this depends on your control of the called function. You have to know that the called function will follow your standards of NOT changing an external object.

Take care,
Joe

>I have to disagree. There's always a need to pass an object by value when you want to be sure that the
>called function will not modify the original object. Otherwise, the constness of the param object cannot be assured.
>
>Another case when this is necessary is when you're using classes that you cannot change. So, good or bad design,
>they cannot be changed and you need pass by value... which is not possible in VFP.
>
>Vlad
>
>>In general there's no need to ever pass an object by value - if you do, I'd say there's a design problem that can be solved easily by creating data members that can be copied.