Hi Walter,

>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 ??
>

Well I don't see a RELEASE or a Release() here, so whatever happens now should be the acceptable behaviour. My concern is with EXPLICIT RELEASE Release().

>>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.
>
In the general case I of course agree. BUT... what about those apps currently running, or under development, which will ultimately break BECAUSE RELEASE/Release() does NOT release as the programmer expected???? I cannot see accommodating both. And I elect to accommodate those who expect RELEASE/Release() to release. After all, anyone who is 'using' this feature to continue referencing an object through indirect reference (my term for the object reference is gone but there are other references (dangling) around) should know that they are playing with fire.

>>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.
>
WHY??? My guess is that almost none would need re-write while any with a hidden problem would, upon re-compile and test, be informed of their lurking deadly error. Those wouldn't need a re-write as much as some corrective code.

>>>- 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.
>
Sure, but I worry very much about the possibility (strong in my opinion) of being hung by our own words. What if, for instance, the VFP Team has established some 'standard', unbeknownst to us, the users), that they will not implement any more set commands (or will only implement more when they can also eliminate an equal number). Our suggesting a new SET option could result in a quick shoot-down, all because of something we don't know. I know that that is a bad example, but I hope you get the gist.
I have no trouble at all with the idea of providing possible ideas as long as they cannot be interpreted as suggestd implementations (or stronger).

>>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).
>
I *DID* read carefully < S >. And I still disagree. Firstly, a (dangling) reference to some property is specific and a RELEASE on that should and would only release that (dangling) reference. As for object references themselves,as I see it, one simply should not RELEASE until one is certain that reference is no longer required. I would not RELEASE an ARRAY if I knew there was later code which would execute and use that array. I see object references exactly the same way.
And that, by the way, is another reason why I said that other references should be left alone, raising an error if used in a command (other than RELEASE) after the (referenced) object has been released.
The alternative is what we have today - with a time-bomb in any app. potentially going off only after production implementation and when under heavy load.

>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.
>
You haven't convinced me yet that there is a NEED to be able to release an object reference MEMVAR without also RELEASING the object. I have no trouble at all with the current implementation when releases are "implicit". My concern is with EXPLICIT releases only. And in its simplest, a program (language) should do what I tell it to do, not what it might think is better/smarter to do.
Outside of a program, as say in a COM object's management, RELEASE/Release() can be handled in whatever way is most appropriate for that facility's objectives.

Cheers,

jim N


>
>Walter,