Jim,

>- if a variable goes out of scope (or an object with references is released) it should work as in previous versions (implicit release).

>Here we disagree very much - continuing the existing behaviour is exactly against the WISH as stated. I have already replied to Jim on this.
I know that you do NOT use RELEASE for this. But since the docs specify (in those hidden 4 lines outside of Help) that RELEASE is to be used, then RELEASE must RELEASE. It is as simple as that.

Jim, If in a piece of code I say something like:

Local oForm
oForm = _Screen.Activeform
oForm.DoSomething

(This I use in toolbars)

and the oForm variable goes out of scope (thus implicit release) should it release the form ?? I don't think so. Besides how do I get rid of this variable without releasing the active form ??

>As regards breaking existing code I have two things to say:
1) The VFP team didn't appear too worried about this when they changed the ERROR return information between V3 and V5. Or they felt they had no choice. Could end up the same here. Sh** happens sometimes.

Well, I truly believe that backward compatibility shoudl be provided ! Avoid the sh** when you can.

>2) The 4 lines of docs do NOT say to use the fact stated to do other things, it says to RELEASE 'dangling references' BEFORE RELEASEing the object. Thos who used the existing behaviour should have deduced that they were doing something 'wrong'.

Well changing this kind of behaviour (like i described above) would definitely mean that 95% of all application should need a rewrite.

>>- If an object is released, all remaining refenced variables should be set to .NULL.

>Here, too, I think that you are getting too specific. The VFP Team should be free to set them to wnatever they deem is sensible/practical. For instance, they might want to set them to some special internal value so that they can recognize the situation and react accordingly.

Of course the VFP team has to decide what the definite implementation would be. In my opinion this could only be one: Setting all remaining refferences to .NULL.

>- You can set the default behaviour by a setting SET FORCERELEASE ON|OFF: with the OFF setting it should work as in previous versions

>Again, an implementation detail best left to the VFP Team in my opinion.

I'm only suggesting a possible solution to describe a *possible* working implementation. Since we are a minority who believe in the redesign of the RELEASE behaviour we should give reasonable alternatives.

>Since Release() now acts the same, how can you prescribe one action for it and another for RELEASE??? Just because you already use only Release()??? Others likely have the same problem with Release() as is described for RELEASE.

The release method is exclusively used for object. Since we definitely want a object to release when we tell it to it MUST release the object.

** WARNING: Read Carefully **

For the release command: It is used for variables. Ones I make a reference (by a property or variable) to an already existing object there *must* be a way to get rid of the variable (or property) without releasing the referenced object (since it is also referenced by another variable or property).

A variable could be released by a RELEASE command. I think it is defendable to say that the object *should* release, although I think there must be a way to release the variable without the attached object. But when a variable goes out of scope (implicit release) it should work as in previous versions: When it was the last reference it should release, when there are other references it should stay.


Walter,