>>>>>>>>>The right tool for the right job. Right? Sometimes PUBLIC is most desirable, and my response to Koen was
>>>>>>>>>to his comment "don't use public," which I do not believe is good advice as it immediately shuts people off
>>>>>>>>>to the idea of ever using a PUBLIC definition, when using PUBLIC definitely has its place.
>>>>>>As Christian pointed out, there are alternatives, making your examples of public not the only way to handle things. PUBLIC is - in my experience - very often a lazy choice to do things which could be done better.
>>>>>
>>>>>There is not question that public variable, more often than not are being, misused. However I think that Rick hit the nail on the head by outlining that global objects are perfect candicates to be referenced by public variables. In our framework, not only the Applic object is accessed through a public variable, but also objects for:
>>>>>
>>>...
>>>>>Since these are all singletons and part of the framework, it makes sense to use public variables for them.
>>>>>Whether you instantiate them as private from the main program or public is really irrelevant as far as i'm concerned.
>>>>>
>>>>
>>>>You would make those PRIVATE at the highest level - even if they are populated in a called component. That way one still has zero NEED for PUBLIC.
>>>>PUBLIC variables can be created anywhere in the lexical hierarchy and that allows one object to break encapsulation. Again, avoiding public forces one to do things properly.
>>>
>>>The always used objects - easy. But things like a logger which may not always be used - that I'd create in a function in a file housing the class and helper code and then public allows creation later (even in the debugger). Having only sometimes needed privates defined cluttering variable space on top layer IMO would be worse.
>>
>>Why? Having the var in the debugger from the beginning is good. It won't just magically appear at some point. Other code is certainly going to be looking for the variable name. It is still possible to remove publics. I'm still waiting for a single irrefutable example where public is the decidedly best approach.
>
>Let me try. You are testing a new approach so in several places the code has to run a difference course than usual. You want a few of your trusted customers to test it. Here what can be done:
>

>*-- in the MAIN.PRG of application
>public lBetaTest
>*-- but for beta testers set the value to .T.
>lBetaTest = .T.
>

>
>Then anywhere in the application where you want to use the test code, you can add a condition
>

>if type("lBetaTest") <> 'U' and lBetaTest
>   *-- you test code goes here
>else
>   *-- code you are testing to replace
>endif
>

>
>I am sure the above can be done with means of semaphore files and so on. But I see no problem with public. I have done it many times.

That only requires a private variable at the main.prg. Therefore this is not an example of a need for public variables.