>Heck Ed, you ignored my question. Not a very efficient way to communicate. Why expand the conversation? We weren't talking about passing values.
>
I'm trying to diferentiate between the concept of "passing an object reference" and "passing an object by reference". IOW, to distinguish between:
oFoo = CREATEOBJ('someobject')
uResult = Bar(oFoo)
and
oFoo = CREATEOBJ('someobject')
uResult = Bar(@oFoo)
where:
FUNC Bar
LPARAMETER toObject
toObject = NULL
RETURN
jRandomResult>I am not familiar with the term of marshalling. I might be familiar with the concept. Good thing I am not going to be tested on this. But why expand on what was said? This was a very simple point two or three messages ago that you've avoided addressing.
>
Marshalling is the process of moving data across a COM boundary The definition in the MSDN Library:
marshaling
The COM technique of allowing an interface exposed by an object in one process to be used in another process.
Marshaling
The COM technique of marshaling allows interfaces exposed by an object in one process to be used in another process. In marshaling, COM provides code (or uses code provided by the interface implementor) both to pack a method's parameters into a format that can be moved across processes (as well as, across the wire to processes running on other machines) and to unpack those parameters at the other end. Likewise, COM must perform these same steps on the return from the call.
Note Marshaling is typically not necessary when an interface provided by an object is being used in the same process as the object. However, marshaling may be needed between threads.
Introduction to COM
See Also Marshaling Details in the Win32 SDK
>>>Anyways, this is not the original point. You said "To actually pass an object by value, you'd have to create a copy of the object in the calling code and destroy the created object copy on return." If you are creating the copy and then working with that copy, you are not really passing by value. You are passing by reference to the COPY. So sure, you can manipulate and change the COPY without changing the original object. But you are only simulating passing the original by value, you are not actually doing it. But your meaning is understood.
>>
Again, when pass by value occurs, a copy of the value is made and the receiving function gets a pointer (an NTI entry) to the copy. When pass by reference occurs, the receiving function gets the original NTI entry. That's VFP byval/byref in a nutshell. Passing an object reference (byval) creates a new object reference, while pass by reference passes the original object reference; the object ref counter is not bumped, and a change to the object reference affects the original reference. There is a significant difference, even if you do not see it.
>>Answer the following. If I pass a char memvar by reference, what is passed? If I pass a char memvar by value, what is passed? Realize that the recieving code doesn't know, and doesn't care, if a byref or byval occurred. It receives the same thing in both cases, a parameter of unspecified type and context...
>
>If you have something to say Ed, why don't you say it? Memory pointers are passed. But what is your point?
>
I'll try to find the phone number for Rent-A-Clue and post it. The basic concept of whether you work with the original thingy or a copy of the original thingy is the issue. The difference in the behavior wrt object refs passed as parameters is significant. And the distinction between passing an object ref by value and passing an object by value (by means of object duplication, so that two distinct object instances that start with identical values but vary in content and state independently) is significant, even if not provided as a simple option in parameter passing in VFP within the context of VFP, because the marshalling interface, a type of parameter passing that we're involved with intimately with VFP, has to use this type of mechanism.
>So if you are flipping through your text books and manuals digging up trivial information on what is happening low level, why don't you just divulge what you've found in an efficient manner instead of asking questions? In other words, spit it out.
OK, you're too dumb to live. I'm trying to get you to think and distinguish between behaviors, because the differences are significant, and serious VFP developers need to understand the differences. Spewing a volume of information without forcing the blob of protoplasm at the other end of the wire to expend neurochemical energy is a waste of time and effort.
FWIW, I'm not digging through obscure tomes to find insignificant trivia to dazzle and amaze you. Clearly we do not agree on what the developer needs to understand about what goes on under the hood. You can't do your job adequately if you don't understand the basis that everything you use is built on.
