>>>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.
>
>Then I would prefer properties on the application main object and use late instantiation when accessing the property the first time. For instance
>

>LOCAL loLogger AS ErrorLogger of Logger.vcx
>loLogger = poApplicationControl.ErrorLogger
>loLogger.DoLog("Error message...")
>

Agreed if only working in one fwk/at one client. Otherwise discrete objects IMO are better, even if only not to remember where in the hierarchy here and under what name thesucker was hiding...