>>I propose that using publics is a bad design in itslef.
>
>PMFJI -- but why? I have never bought the "just because it is" or "because such and such famous guru says so" or "because it is accepted practice" arguments. There has to be a reason - and not that there isn't one here - I just haven't seen it listed (unless I missed something in the thread)
>
>BTW - I use only one public variable - to hold my app object. I ask you to tell my why using one private var instead would be better in any way - performance, maintanability, security, stability, etc.?
>

Ken,

This has to be the fifth time I have answered that question in the last two weeks.

The ONLY reason for a variable to be declared public is so that it is visible after the declaring routine ends. You, as many poeple do, are confusing global visiblility with public scope. A private variable created in the startup program of an application is GLOBAL to that application. Declaring that variable public has absolutely no effect on the global visibility, it doesn't cause it or destroy it. But declaring the variable public does cause that variable to exist beyond the end of the startup program potentially interfering with the dev environment, any thrid party add on products that you use etc.

Now, the one "feature" that a public has over the other scopes is that the variable will last beyond the end of the routine that creates it. The problem with that is this, if you need a variable to out last the routine that creates it you have a serious external coupling problem as well as a problem with cohesion. You have routine that depends on variables that they do not create, your routines are name dependent on variables. Both of these cause a situation of added effort during maintenance and enhancement phases. In this environment if you edit one prg, you have to either know every other routine that calls or may call the one you edited and you have to examine them to be sure your change has not broken something somewhere else. (this is an external coupling problem)

Any routine should contain all it needs to do what it does within the routine itself. Any data that is supplied from the caller should be received as parameters and data to be returned should be either passed back on the RETURN line or be the result of a pass by references parameter that is modified. Having a routine declare a public variable so teh caller can then see it is a problem with cohesion. The cller is dependent on something that the called routine may or may not do, that is it is dependent on more than the purpose of the called routine, it is dependent on what the called routine decides to name the public var.

A simple example;

PUBLIC lcVar

Make that program and run it twice. Now here you have a simple single prg application and it is easy to fix the bug, but what about a real application? Where would you look to find the other public declaration? Would you just release the public before declaring it? If so, how do you know that the release doesn't break some other code that is depending on that variable.

Summary: There is nothing wrong with the public declaration, it works exactly as advertised. There are many things wrong with a design that requires a public declaration. Finding a place in an app that needs a public decalration to get it to function correctly is finding a design problem that is much better fixed by changing the design than by using the PUBLIC bandaid to hide the design flaw.