Believe me Jim when I say that I understand your position clearly.

Let me also say that my proposal has a second option to NOT RELEASE but inform the program and even a third option to simply explain fully in the RELEASE command's documentation. Of couse I still want the first option to be implemented.

That said, I still disagree with your position. I feel that programmer A would likely use LOCALs for such and that they would be implicitly released (without adverse impact on the object whatsoever) or that s/he could set it (them) to NULL if other were used, again without impact on the actual object.

I am of the opinion that the present handling that you rely on is an "accidental" by-product of the way RELEASE currently works. Similarly to the way VFP 3 would execute Refresh()es wherever they were coded but which the VFP Team changed in subsequent releases.

In any case, the primary objective is to either have RELEASE actually release when instructed to do so or to inform the programmer when RELEASE does not do so.

It is unfortunate that the wish was submitted prior to all of these valuable discussions because it could have been written with much more detail. In fact it might even have ended up with option #1 removed in part, being specified only for the Release() method (though i admit that I would have been royally tenacious before that would have come about).

Regards,

Jim N

>Jim,
>
>First I will jump back to the GetHook method of my application object. It creates objects and returns references to them. If a second routine calls for the same object the gethook simply returns a reference to the object that already exists.
>
>So if programmer A writes a rotine that need MyWidget object adn calls gethook to get it the routine will have a reference stored somewhere, perhaps a variable. If Programmer B working on a different part of the system in another sate also use gethook to get Mywidget the gethook will return a refernce to it. Now if Programmer A, trying to be neat and clean up after himself release his memvar, that would blow away the object in the application's Hook collection adn in the routine that Programmer B wrote as well.
>
>My position is that RELEASE MEMVAR should release a memory variable and nothing more. It should not have any effect on any other memvars anywhere regardless of what they are or what they point to. If one want to destroy an object completely then one should call a method in that object to destroy it. At least the object would have the ability ot know how many references there are and could systematically release each of them (of course the class architect would have to create the class that way).