>I don't think that would make it any easier to debug at all. Trying to find who killed the object could be a daunting task. Plus all the method errors that would ensue trying to use a nulled reference would complicate life to the point that a CLEAR ALL is the only out. Also what is someone coded release this.oReference?

The further I thought of this, the more complicated it got. First, automatic references (like .parent, .controls[] and such) should not be counted at all. Another example that came to my mind - take a common toolbar for instance. Nobody but the last form should release it, right? So your form should check for existence of other forms, and that's not elegant either -
you may have a form which doesn't use the toolbar, so it won't release it (won't know about it), so your form-in-exiting has to check for forms which use it... seems to get more and more complicated.

I've even had an idea that all VFP classes should have a .harakiri property, default .f., which would set the .release to fire regardless of reference count. But then, it would take lots of code to implement (unless there's a simple mechanism to see if a memory block a variable references is released or not).

One thing would be nice to have, and JimN is right about it - .Release should return .f. if it fails because reference count is not zero when it attempts to release, or the .RefCount should become an accessible property. Simple existence of this property would give some insight to novices, and including it in the help for the .Release method would clear lots of things to them. Speaking for myself, I had no idea of how the variables and the objects they referenced are connected, until I read it here.

>>A real thing would be to have, of course, the this.references[] collection, and it should, IMO, keep the _names_ of the variables/members/properties which are referencing it. I can imagine nice chaos if this.references[] kept references. Nice recursive chaos :).
>
>Yeah they'd have to be pseudo references for sure, ie don't get reference counted. But it would be hard to do, because at createobject() time I don't even think the memvar that will hold the returned value exists yet? That might be worth a test: goObject = createobject() does goObject even exist at .Init() time?

I tried it, and the variable doesn't exist until .init() exits. AInstance issued within .init also finds 0 references. This means that .init increases the reference count (if successful) and .release decreases it (if successful). The whole story starts making sense. The way things are, keeping a .references[] collection would actually have to be delegated to the assignment statement, i.e. the assignment of an object (createobject()ed, copied or whatever) should pass the variable's name back to the object, so it would include it in its .references[] list, checking if it's already there. Also, the same assignment would have to check if the variable referenced another object prior to that, and remove it from the .references[] there. Doesn't sound like an easy thing to do, and would probably need rewrite of some of the VFP kernel...

>
>I can't say for sure, but I seriously doubt there is an internal References[] collection in there already.

...therefore I've also come to conclusion that it never existed, else we'd have seen it in the PEM or Debug/Locals window somewhere.