Jim,

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

I have not been following the Thread all the way through - sorry if you are repeating


>The ONLY reason for a variable to be declared public is so that it is visible after the declaring routine ends.
or outside the routine
> You, as many poeple do, are confusing global visiblility with public scope.

I assure you I understand the difference

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

In my case - I explixitely destroy the ONE public variable called in my startup program at the end of my start-up program -


> Having a routine declare a public variable so teh caller can then see it is a problem with cohesion.

I agree - a bad, bad design ... I NEVER argued that anything of this sort was good.


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

I agree with this too - and the operative phrase is "a design that REQUIRES a public declaration" - My argument is that a properly handled and destroyed SINGLE app object public var is no "worse" of a design than a single private var - especially given that private vars are Fox aberations anyway.

Ken