Import concerns revisited

[Jari-Matti Mäkelä]

Georg Wrede wrote:
> Walter Bright wrote:
>> 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!

A good point.

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

I think when two modules are somewhat tightly coupled, public import
should be used instead of manually importing everything all over again.
It's pretty analogous to the package management systems of modern Linux
distros: installing (importing) a package (module) also installs
(imports) its dependencies.

IMO the biggest issue here is that even practice shows that private
imports are much much more common. It's quiet natural since the main
principle of OOP languages is to keep public interfaces as minimal as
possible. It's annoying as hell to publicly import everything. At first
it looks like it's much easier to code that way. After ~50 classes the
future still looks quite bright. But then you import that simple
helloworld-widget from GUI or some other huge library (I'm talking about
QT 4.2 sized GUI here, not DUI). Bang - 50+ name conflicts. Why did this
happen? Because too much functionality was exposed to the child modules.
If only that graphical arbitrary precision math library object hadn't
imported that 3rd party implementation of sound stream. Importing to a
namespace (import foo as bar) can be used as a workaround, but it really
isn't the solution. It should only be used in some "rare" situations,
where refactoring otherwise becomes too expensive. (at least that's how
I see it)

Specifying the correct protection attribute for every import isn't a
trivial task at all. I think one should spend significant amount of time
considering the rationale behind every import. The task can be
impossibly difficult for even experienced programmers and therefore
should be made as "safe" (=does not poison namespace) as possible.
Luckily importing privately by default fixes this.

-- 
Jari-Matti