I think reference counting is a HUGE plus and fairly mandatory to a good OOP language. I don't know how you would get by without it. The only problems I've ever encountered are when my classes are not well encapsulated and have dependencies on other objects that they are not responsible for and just expect to exist. I've learned (through some trial and error) that this is always bad design.

Objects should always instantiate and release all resources that they require. I can't think of a properly designed example where I would want to release the resources of an object that was in scope somewhere else. I would, however, want all of those resources to be release when the object was no longer in scope ANYWHERE. The goServer example from earlier in the thread is the best example. Why would I want to be coding in each client for the existence of goServer? And then, if it's not there and I need it I'll probably have to re-instantiate it, with every one probably ending up with their own copy of the object afterwards.

The References[] collection is a better idea, in my opinion, if such a thing is possible. From what I understand about the way reference counting mechanisms work it would be difficult.

Hope I'm not butting in here...

Eric Shaneson
Cutting Edge Consulting

>Jim,
>
>Let me say a wishlist item I'd much rather have is the ability to backtrack a reference and find the object/memvar that is keeping the reference count from going to zero and thus allowing the object to be removed from memory. Something on the order of a References[] collection.
>
>>>goServer = createobject( "oServer" )
>>>x.oServer = goSever
>>>y.oServer = goSever
>
>>I do contend that this example is far easier to discern in app. testing than the disappearing memory problem. I don't see either as chaos, but I sure see the present situation as much harder to determine.
>
>Yes, it's obvious there in those 3 lines of code all right together, but practically in an app those lines of code aren't anywhere near each other. Either in terms of source code or in app execution time.
>
>>Again, to me, this represents an even worse situation - what business does VFP have "using" an object which I intentionally (tried to) get rid of???
>>Do you truly believe that this is legitimate?
>
>Yes, it's completely legitimate. goServer is NOT the object. goServer is a memvar that references an object in memory. Two distinctly different things. The posted code shows three users/clients of the oServer object. WHen you RELEASE goServer all you are doing is removing one user/client of the object.
>
>>Maybe an alternative to my original proposal, though, would be to have the VFP editor *automatically* insert code in the referenced object's Destroy() to remove the links. Sort of, as you code a link, it automatically inserts the de-link code as needed. Not "intellisense", but 'intellirid'.
>
>Since Xbase is weakly typed, we are both out of luck and handed a solution. Have each one of your lowest level classes call a CleanReferences( this ) UDF. You can pay the performance penalty of using amembers() and search for properties of TYPE() "O" and get rid of them.
>
>Personally, it's just one of the things I automatically do. If I create a custom property moSomeObjectReference I set it .NULL. on the property sheet and add a line in the Destroy() method:
>
>this.moSomeObjectReference = .null.
>
>I just consider this good standard programming practice.
>
>>I suspect, based on reading I have done and also from what Rick S. had to say on this, that Win reference counts are implicated. And, personally, I think it is more appropriate to have a memory page fault or an app crash than to have the program refer in any way to something which has been eliminated (as far as the app is concerned). But, of course, VFP would have the opportunity to intercept those failures and tell us what the problem was in a considerably cleaner way.
>
>Windows does do some reference counting of it's own internal resources. It has to... just like VFP has to keep object reference counts. Whether VFP objects are using an internal windows mechanism or have their own int reference counter is an internal detail that we dont' care about.
>
>You would rather have your app crash because you have two independent forms that both use a MenuServer to crash if a third party releases it's reference to the same MenuServer? That's what I mean by chaos, you have a system that becomes an order of magnitude harder to debug. I'd much rather have the MenuServer available until all of it's clients have said they are done with it, then and only then the MenuServer can hit the bit bucket.
>
>>Of course I agree with your bottom line. All I am saying is, if you haven't done the proper job of cleaning them up, then let there be an immediate penalty when an attempt to refer to a RELEASEd object is made. For sure, don't go allowing the use of something which I have said I want out of here!
>>And it *IS* different than the cases you cite, because now I tell the sucker what I want done and it blatantly ignores me. Even if it told me 'no can do' I would be far better off.
>
>It seems like you believe that goServer is a higher level power than x.oServer, when they are indeed just the same. They are both simple obejct references. I've used my share of CLEAR ALLs during development especially when there is a code error in the Destroy() method and the object basically can't .null. out it's references. But that's design time, not run time.
>
>I go back to pointing out release goServer does work, it does not fail the memvar is gone, the objects reference count was decremented. If the reference count hit zero the object went away, otherwise the object is still sitting there available to the other's using it.
>
>In the modeless environment that I work in it is so handy to have objects sitting out there waiting around. Run a form, find something that needs fixing, close the form, edit the form, rerun it. No need to build a project, no need to start/stop a whole app. The only time I do a build is when it's time to make an exe to send the client. That productivity boost is a tremendous feature of VFP.