Import concerns revisited

[Dave]

Walter Bright wrote:
> Lars Ivar Igesund wrote:
>> Walter Bright wrote:
>>
>>> Lars Ivar Igesund wrote:
>>>> Well, who did ever say that was a good idea, everything public by
>>>> default? ;)
>>> I did <g>.
>>
>> Right :) I don't agree.
> 
> Let me explain why I think default public is a good idea.
> 
> It reduces clutter in sample, example, and quick programs. Access 
> security is an advanced feature, one that's invaluable for a complex 
> project, but is just in the way for smaller ones.
> 
> I don't mind at all when crafting a carefully designed, reusable module 
> that 'private' needs to be explicit. It helps document the intention, 
> and lends the impression that the designer did put some thought into the 
> code.

I think you'll get most of us to agree for access control in general and 
my experience with the language bares that out.

For imports though, many of us feel that private shouldn't need to be 
explicit because we don't want the side-effects (by default) we may have 
little control over for such a sweeping statement as 'import' (that may 
import thousands of symbols, and that may increase geometrically as more 
top level modules import their own, etc...).

> 
> But when writing illustrative sample code, I feel that having to add in 
> 'public's is distracting from the point (unless, of course, the point is 
> about how access control works!). I see this a lot in sample C++ code, 
> and it is distracting, to me anyway.
> 
> And it's just plain irritating when writing smaller programs where 
> access control is quite irrelevant.