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

Right. But in many cases you don't have the control. And even if you have absolut control and you know 100% that
a function doesn't change a parameter, it's still impossible to be sure that you or someone else won't modify this
behavior in the future.

My point is that it's very important to have a mechanism built-in the language that allows the programmer to control
how the params are passed to a function (by ref or by value). Almost all languages give this control and VFP is
no exception... except for the object params. :) It's easy to say that this or that is bad design and that it should
be changed. The problem is that no design is perfect, programmers are not perfect, source code/modules must
be integrated, old components must be integrated with new components, etc, etc, and sometimes one simply
cannot change everything that must be changed.

Vlad