Mark,

I must say I really don't like the tone of your response. I know all about "garbage collection", having worked on IBM MFT/MVT/SVS and MVS ( as a Systems Programmer, writing lots of Assembler) for more years than you can guess, so please stop with this attitude that I really don't understand things!

You write of my knowledge of anything and proceed to ignore the real though behind the suggest, taking comfort that *you* know how it works and can deal with it, so that's a good enough situation.

I am talking about something just a little larger, like *improving* VFP, primarily so that coding is eased and so that learning is easier.

Gimme a break on your statement that "Any programmer who tries to learn like that in this day and age is not going to remain in the field for long." - how else do you expect people to learn a language. . . make up commands in their heads and try them to see if they are recognized??? Or to read about a command but ignore the description of its operation, rather "observing" what actually happens and letting that be the proper description of its operation?

>>Well, WIN *does* keep reference counts for objects instantiated on Servers by Clients (if that's a reasonable way to put it).
>Oh, sure. Windows does plenty of reference counting. But it's such a simple concept that it wouldn't make sense for VFP to ask Windows to do its bookkeeping for it.
>
You are only guessing here, so don't make it sound as authoritative as you do. There is an equal chance that I am correct on this *guess*.

>>*OR* if VFP mimics that way of handling object references internally, then I contend that this is WRONG WRONG WRONG.
>
>Reference counting is a general-purpose technique. There'd be no need to "mimic" Windows to provide it. It's the core of garbage collection.
>
I guess you don't know what mimic means. It means, essentially, to copy. It seems quite clear to me that the VFP programmers simply copied what was done elsewhere, paying no mind to what the actual situation is within VFP nor making the effort to think things through and to code things differently in VFP. There is clearly, in any **language**, no need (indeed, no sense) to not execute a command as instructed or, at the very least, to report the only partial operation of any command. It is quite clear that you cannot make the necessary distinction between an OPERATING SYSTEM and an APPLICATION.

>>The OS has system-wide responsibilities, while any VFP app. has only app responsibilities. It is not proper that VFP treats my app as if it has system-wide responsibilities - it should do what I tell it to and let me face the consequences.
>
>If that's what you'd really like, then I'd suggest C++ (seriously). But even in C++, the string class does reference counting, and it has no system-wide responsibilities. This just isn't an OS issue.
>
Here again there *is* a difference between an OPERATING SYSTEM and an APPLICATION.

>>Have you bothered to read ther VFP 6 (or 5 for that matter) Help for RELEASE, RELEASE ALL the Release method or the Destroy event? It sure looks/sounds like you haven't, because had you done so you would know that the concept of reference counts is *never* mentioned. Furthermore it explicitly states, for all of them, that the thing being released is removed from memory!
>
>Well, what are you going to trust, the documentation or the way it actually works? My goodness, if we nattered on about all the faults in the VFP documentation, we'd be here forever.
>
One of my longer-term objectives has been to get the VFP documentation cleaned up so that novices had a chance to learn the language, thus GROWING the VFP population. VFP 6. was apparently aimed precisely at that too, but they failed to seriously update the Help or the Programmer's Guide, so I don't know how they expect to achieve that objective.
You, on the other hand, are satisfied with things as they are, having invested (like me) the time to learn most of the countless anomolies in VFP.

>>I know a little differently from additional reading and from experience, but what about the novice who is just starting (and keep in mind that, unlike you and I, most movices do *not* use the WEB to look for Help or knowledgebases or anything - they use the books and the Help and try to code.
>
>Any programmer who tries to learn like that in this day and age is not going to remain in the field for long.
>
This is crap of the highest order.

> What do you think *THEIR* expectations would be??
>
>I think they would agree with yours. And they would learn differently, once they got into a situation where it was necessary. After all, intricate object dependencies are not common in novice code (or at least they shouldn't be).
>
You're wrong here for over 95% of those who give VFP a shot. Yes, less than 5% will stick it out, but the remainder will simply give up and move to something else.

>>See above. *NOT* at all to "spec". Though I will have to admit that very little of the actual "specs" are to be found in the documentation - only in KB articles where a problem is reported and then we are told what the spec is. Remember the phrase "performing as designed" and how often that is the response??
>
>The thing is, Jim, the way RELEASE works makes good sense to at least some of us. And there's no way that MS designed this behavior by accident. That's what I mean by "to spec." It's not the same as "as documented." :)
>
Yep, it does to you, who cannot distinguish between an OS and an APP. And who already knows the language. and who is happy as things are.

>>I don't know where you are getting your "client" from.
>
>A client is something that requests services from something else. In this case, the clients are all the variables and properties that point to the object you want to RELEASE, but can't.
>
There you go again, mis-appropriating a term. a "client" has a much more particular definition in the WIN world. You cannot just go around applying the term to things you make up internal to an app and expect people to understand what you mean. You should use a different term to describe such constructs, so that conversations like this one can proceed on a level basis.
Summarizing, *your* 'client' is nothing like a "client".

>>Of course I, in *my* program, *will* have full knowledge of every 'client'. Should I err and release before all of my 'clients' are done with an object, let me fail (it is my fault, after all).
>
>But you said before that object are created "who knows when and who knows where". Which is it?
>
Are you really that thick??? I meant, and you should have caught, that objects are not all created in the same bit of code, but rather their creation could occur anywhere, anytime in an app.

>>This is far far better than a memory leak which is only detected *AFTER* implementation.
>
>What memory leak?
>
You really don't understand the problem, do you! Let me try to simplifiy it for you: if RELEASE doesn't release when commanded, and if in my app I repetitively create/RELEASE objects, then in a volume situation I will run out of memory becuase of all those UNreleased objects which I told it to release but it didn't. Is that clear enough???

>>I think you give VFP designers too much credit. It is far more likely, from the (paltry) evidence available, that they simple mimicked Win and/or VB behaviour and gave this very little thought.
>
>Only to someone who's not really familiar with garbage collection, a technique that has been around for decades.
>
Please refer to my first paragraph, oh knowledgeable one.

>>See above again - nowhere in Help am I told what you believe and what I have come to learn!
>
>If you trusted Help to tell you everything you need to know to program VFP, you wouldn't be where you are today.

Right, but that's also why the VFP crowd is shrinking rather than growing!