>>Jim, it's quite simple. If you like garbage collection, you have to accept reference counting. If you don't like garbage collection, then you're using the wrong language.
>
>Good one...
>
>+++ Rick ---

Well, Rick, you may think it was a "good one", but what it actually says is that Mark has neither read the proposal (much less understood it) carefully nor given it a scintilla of serious thought.
It says the same thing for you, too.

Maybe you should get off your high horse on this one.

About "garbage collection". . .

As I understand things, "garbage collection" is really a misnomer, and it would be more aptly called 'important factors tracking'.
What I mean by this is that factors like Forms displayed/displayable, allocated/free memory blocks, files open (including devices), file buffers, etc are tracked, some by the OS and some or possibly all by VFP (in order to be able to pre-empt any operating system actions) so that, in the event of a PREMATURE end (either because of a problem (eg GPF, etc) or because of sloppy programming (eg programmer exits without cleanly closing things down)), they can be taken care of so that nothing is lost. At that point, of course, there is no real need to 'clean up' allocated/free memory because the OS is soon going to wipe out the address space anyways.
Now it is clear that object memory is *not* specifically tracked by VFP (or the OS) - witness an object (say OBJECT-X) being repetitively created/released causing a memory leak which can result in failure if repeated too often. Also keep in mind David F.'s assertion that a RELEASE *does* eliminate the object reference (as seen by a DISP MEMO after a RELEASE), rendering it *impossible* for the VFP programmer to subsequently RELEASE the memory no matter how he/she tries to, so it has to stay occupied until end-of-job.

*IF* the object were actually released as commanded, *no* memory leak would occur. "Garbage collection" has *no* impact here.

Jim N