>Peter,
>>>
>>>I pretty much walk in lock-step with JimB on this. I believe he said (and I'm paraphrasing here), that you should know the rules, know the reasons for them, and realize the consequences before breaking them and be able to quanitatively justified the reason.
>>
>>George, didn't JimB criticize your use of _screen.addproperty() in one of the messages?! (JimB, didn't you?) BTW, I agree with JimB and you that one should know the rules.
>
>I've read Jim's posts in this thread. However, I don't recall him been critical of this method. It has certain significant advanges over both PUBLIC and PRIVATE variables. If he was, I don't have a problem with it. I have the highest respect for JimB, and he, like you and I is certainly entitled to his own POV. For myself, I know the rules, and feel justified in the implementation of this method.

Okay, I assume JimB 'might not like it'. :)

>>>So here's the rule: Don't use public variables.
>>
>>Well, I can't recall even a single spot in the vfp-documentation that states this rule. And in the end that documentation is worth more - for the international vfp-cummunity - than Jim's set of rules.
>
>I shouldn't have used "public". I meant global. Nevertheless, there are times when they are required. The programmer should be aware of this and not use either public or private variables indescriminately.

Your statement "Don't use public variables" contains the correct word 'public'. JimB wants us to use the word global for variables/properties that are visible to all routines and objects in the application. See Re: Public variables Thread #667392 Message #668175
There he also states that global variables should be declared as private, and never should be public.
I don't mind using the word global for such variables, although I like the word private somewhat more. To me, intuitively, public and global are synomyms.
The 'problem' I see with the _screen properties is that they are like public variables, because on cleanup of an application you can't simply cleanup those user defined properties. You'd have to code. If, instead, you would create a custom object (the application object?!) on init and then would use that object for the global properties, then on cleanup of the application that object would also be released and so would all those global properties. I think that's what JimB 'likes' me and you to do.

But let me assure you that I see advantages in (ab)using _screen.

>Jim stated the overriding reason for not using "public" variables, namely that it can impact things higher in the call stack. I think that that's pretty much stated in the documentation. The rule about not using "global" variables is simply a programming principle and, therefore, I would think be beyond the scope of the VFP docs.


>>>Here's the reason: It breaks encapsulation (as Jim mentioned) plus it tightly couples the code module to its environment. This makes the code less portable.
>>
>>Using a user defined property that's tied to the _screen object is equally 'dangerous'. What guarantee is there that the property exists at the moment that it's used in code? No guarantee at all, that's to say, not more guarantee than we have with regard to public variables. In both cases, robustness is a matter of the programmer's discipline.
>
>Certainly. However, the use of an object reference tied to the _SCREEN object as opposed to either a public or private variable assures that it must be explictly destroyed, and cannot be accidentally released by a statement RELEASE ALL LIKE...

Agree. And if that's exactly what I want in a certain situation, then I'll certainly use it for that purpose. See my VarX() article on, what I called, enduring variables.

>>>One of the goals of both the structured programming and object oriented paradigms is re-usability. Similarly, they share the same techniques in achieving this: modules should exhibit a high degree of cohesion and be loosely coupled with their environment.
>>
>>Sure. I agree, theoretically. In practice I find that it's often enough not worth the extra effort to go to the extremes. In those cases I develop routines, forms and classes that have some interdependency. But I always DOCUMENT those interdependencies! And one might view those interdependent things together as ONE virtual object. It's all a matter of perception and that perception must be made clear to the next developer through documentation.
>
>No problem with this. I often write my comments, for example, before writing a line of code. What I don't do is comment what I feel to be "the obvious".

Same with me. However, the problem is that what's obvious to you/me isn't always obvious to the next developer. But then of course that next developer is a nitwit, right?! :)

>>>
>>>Another goal of both is a reduction in the time required to maintain the system. Maintenance and modification take up far more time than implementation.
>>>
>>>The use of public variables goes against both these goals. Therefore, before using them, one should not only be aware of it and the consequences, but quantifiably justify the use as well.
>>
>>BTW, I appreciate the discussion, George. :)
>
>Thank you. Me too.