Walter,

>Jim B,
>
>>I see a major problem with this behavior for RELEASE. If I have a utility object that is instantiated by my application object and other objects call the application object for a reference, then releasing one reference would release the object and leave an unknown number of objects with no access to their utility object because the references were NULLed.
>
>In my thoughts it should be implemented in the following manner:
>
>- an explicit RELEASE command should release the attached object, maybe accomplished by extra parameters [FORCE]|[NOFORCE]
>
>- 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.
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.
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'.

>- if a release method of an object is called. The object *SHOULD* release (aside from the query unload feature).
>
>- 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.

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

>In my opinion this is a enhancement request. I definitely believe that the behaviour of the release method is a design err. Your example of the RELEASE command might indeed be a problem for *at least* existing code. Therefore backward compatibility should be provided.
>

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.

>Are there other black holes we forgot ?
>

I do not think that this particular one was a "forgotten" black hole.

Cheers,

Jim N


>Walter,