<head>
<title></title>
</head>
<body>
<div class="userStyles" style=" font-family: Arial; font-size: 12pt; color: #000000;">> I have two problems in forcing the programmer to think about import ordering:<br>
> 1. It does not scale. If you have big systems it is hard to hold in your head<br>
> all the import relationships. It is better to have the compiler figure it out<br>
> for you and do the proper checks.<br>
> 2. It breaks encapsulation. If I (module B) import a module A, I should only care<br>
> about its public interface, not how it is implemented. So if the module A<br>
> re-imports types and indirectly could mess with the import order of my<br>
> module B, we have implementation details leaking through. So when the<br>
> implementation changes the import order of the client modules could break.<br>
<br>
These are VERY important points.<br>
<br>
The programmer absolutely should not care about import order. That's what computers are for.<br>
<br>
I'd say "make the TOOLSET figure it out", as opposed to "make the COMPILER figure it out", keeping Michael Franz's "slim binaries" work in mind, that deferred actual code generation to load time. Load modules were essentially just parse trees for the source code modules. The actual code generator was in the loader. It worked because file read time absolutely dominates compile time.<br>
<br>
--John R. Strohm<br>
</div>
</body>