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.

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

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

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

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