Import concerns revisited

Georg Wrede georg.wrede at nospam.org
Wed Jul 12 06:21:22 PDT 2006


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.

Hmm. So D is becoming an educational language, like Pascal.

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

If somebody wants a public import, then /that/ intention should be 
documented -- not the other way around, right?

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

Problem is, readers of illustrative code tend to copy them in their own 
first programs, then make similar code, and in time larger pieces of 
code. They frequently miss the transition point where they should change 
their behavior (in this case, to start using "private"), and the end 
result is large code with small-code practices. Very bad, and you can 
see it all over the place!

> And it's just plain irritating when writing smaller programs where 
> access control is quite irrelevant.

Code should be written so implicitly public imports are not needed!

If I import some high-level module which in turn imports some low-level 
module, and I happen to need stuff from that low-level module too, I 
sure as hell better import that explicitly in my program.

Code has to be clear, deliberate, and lucid. This is not achieved by 
good-luck chained imports. And definitely not by good-luck chained 
implicit or invisible, or even gratuituous imports.



More information about the Digitalmars-d mailing list