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

So here's the rule: Don't use public variables.

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.

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.

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.