Import concerns revisited

[kris]

Jari-Matti Mäkelä wrote:
> 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.
> 


All good points.

In the FWIW category, Mango makes all imports private expect for those 
that expose symbols used somewhere important; such as arguments to class 
constructors. The idea was first proposed by Chris Nicholson-Sauls, and 
it is one I found to pay big dividends overall (thanks to Chris).

I noticed that an import count was performed on Mango, and the public 
imports were 18% or something? That seems high to me, so perhaps we've 
been slacking ;D

Either way, all imports in Mango are (or should be) explicit in terms of 
public, private, package, etc. When it comes to code, it is often useful 
to explicitly convey intent behind an action.