>>>>George, that's clever and I'll certainly use it whenever appropriate (appropriate according to me). However, I see one problem. Jim Booth stated (in other words) that we must guarantee that all variables get out of scope when the application ends, in order to prevent interference in a next run application. Added _screen properties won't get out of scope, so Jim would disagree with this usage?!
>>>
>>>Peter,
>>>
>>>I wouldn't dream of saying whether or not JimB would disagree. Certainly, however, I'd have to make the point that a global property/object is different from a global mevar. I'd be lying if I said that back in the FPW days, I didn't use the PUBLIC statement, because I certainly did. However, how I used the variables, may have been significantly different than the norm. They were used to hold global constants, that no program ever modified. For example, my applications run at 6 different manufacturing plants. Each plant has a 2 character "number". For example, I work at Plant 15. Some applications run at Plant WE or 11, 12, etc. The applications produce reports. The reports have to show the plant number. So, I used a global variable, initialized by data in a table to store this value. In VFP, I can use a property of the _SCREEN.
>>
>>George, no problem for me. But a public variable can do as well, can't it? In case I'd intentionally want the value to be omnipresent across applications, I'd certainly use _screen. That reminds me of VarX(), a function I wrote in 1996. An article about it was published in Foxtalk. This function also enabled us to make what I called 'enduring variables'. I guess the _screen.addproperty() feature has made that function obsolete, at least for a part. (http://www.pinnaclepublishing.com/foxtalk/FTMag.nsf/Index/04E151AF88FA48DD852568E90052F28E?opendocument)
>>
>>
>>>The other thing is that application objects can provide services that all applications may have need of. In this scenario, there's no need to destroy the object when the application changes.
>>
>>Sure.
>>
>>>I do believe, however, in what I call "Mom's Rule"..."Put things back the way you found them." Any changes that an individual method may make to the global environment are restored before the method terminates.
>>
>>Good rule. And IMHO it doesn't disqualify the use of public variables at all.
>>
>>Jim Booth, and probably others, stated that a publicly required variable in a main program should be declared as private. I know that the effect is the same, however, I make a habit of only declaring variables public - instead of private - in the main program. This enables me to distinguish those variables (g...) from variables that were declared private (p...) elsewhere. And a simple RELEASE ALL LIKE g* in the shutdown routine can almost guarantee that the application will clean up as required.
>>
>>BTW, I hardly use public AND private variables, but I'll never tell people that they're kind of forbidden.
>
>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.

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

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

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

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