OK, Jim, I'll give this a shot to see what happens. . .

>>I would not objct at all if, in their adoption of this, the VFP Team did as you suggest and permit a way to release a memvar without releaseing the referenced object. As long as we could also definitely release the object when we say so.
>
>Jim,
>
>Just as a devil's advocate question, what would you do if you released a memvar and that caused an object to be released that something else was depending on because its referencing variable was not yet released?
>

First and foremost, I would call that bad design/programming. I believe that, at the application (as opposed to the OS) level I should only ever release what I create. And this possibly is true at the OS level too where, I suspect, my CreateObject is actually intercepted by the OS.
In addition, it is my position that if that happened it would SHOW ME the error of my design/programming because now I would get an error that I could deal with.

>To me this really sounds like a violation of encapsulation. If routine A creates an object and then passes a reference to it to routine B, then routine B should NOT be able to blow away routine A's object. However, routine B should be able to do anything it wants to its own memvar without concern about any effects on routine A.
>
Well, is the reference passed to routine B REALLY a memvar BELONGING to A??? I truly wonder about that, feeling that it just as easily BELONGS to routine A.
And why cannot routine B just set that variable that you call ITS own to NULL instead of releasing it???? Surely we can agree that routine B 'knows' that the parameter (passed) in question was an object reference, so surely it can set any subsequent reference that it decides to make to NULL instead of RELEASEing it. In fact the general wisdom on UT has been to set such object references to NULL as a matter of course, People who followed this technique would be just fine (at least I cannot see anything troublesome that way).
And, as I said above, if the RELEASE command is used then there will be a failure rather quickly. That *is* the objective here - a failure in development testing rather than in production and under load.
We are fond of the term "encapsulation". Now I am not arguing that encapsulation is not important - I agree that it is a prime factor in OOP. But with VFP is it not actually true that anything that references a field in a table/view by definition breaks encapsulation? I truly am not versed on the subtleties of these definitions as you are, but it just feels so to me.

>If routine B has to concern itself with whether or not routine A still needs the object then there is a violation of encapsulation because B needs to know what A is up to and B can blow A away.
>
Personally I do not see that routine B )or A) has to concern itself with anything special. First, it shouldn't RELEASE that which it didn't create. Secondly, it's not necessarily its memvar to release. And for those that it does create on its own and refer to objects or properties passed to it, NULLs should serve all well. So the amended Help for RELEASE, as well as doc amendments elsewhere could state these as the coding guidelines.


>There is also tight external coupling because B must have intimate knowledge of A in order to not blow A away and A must have intimate knowledge of B in order to protect itself from being blown away.

With the "rules" preceding I think that concern would disappear. But anyways I argue that there is generally always an intimate knowledge required between objects that use each other. For instance, we cannot use just any parameters, but those that suit.


Regards,

Jim N