On 12/18/16 1:03 PM, Joakim wrote:
I largely agree with Dmitry. Ilya refactored several Phobos modules to
use scoped, selective imports much more, and I pitched in for some
remaining imports in the largest modules, so that only these
module-level imports remain, ie those necessary for symbols imported in
template constraints:
std.datetime - https://github.com/dlang/phobos/pull/4373/files
std.uni - https://github.com/dlang/phobos/pull/4365/files
std.string and std.traits - https://github.com/dlang/phobos/pull/4370/files
Yah, there's been a lot of good work (Jack Stouffer did a lot as well
IIRC) on pushing imports inside. The following searches should be relevant:
git grep '^\(private \)\?import' | wc -l
yields about 426 top-level import declarations. The number of indented
imports is 4605:
git grep ' *import\W' | wc -l
So we're looking at 10% of imports being problematic. Sadly, they turn
out to make things quite difficult for Phobos. Last time I looked at the
module dependency graph it wasn't a lot better than it used to before
scoped imports. (I don't have it handy... could anyone please produce it?)
When I first saw this DIP, like Dmitry I was happy that we could get rid
of those too, but the more I see these horrible syntax suggestions for
what is really a minor convenience, I changed my mind. std.datetime,
the 35k line (17 kloc according to Dscanner) beast of phobos, only needs
20 or so symbols at module-scope. std.uni- 10k lines, 4.2 kloc- only
needs 17 symbols, all from the three modules Dmitry mentioned. I don't
think his workaround of splitting up modules is even needed for such a
low amount of module-level imports.
This paragraph is a good example of a couple of counterarguments that I
think point directly to flaws in the DIP:
(1) The DIP uses Phobos as an example, so it is applicable mostly to
Phobos. In fact, Phobos is among the systems that would benefit least
from the DIP: it has only druntime as dependency, and is distributed in
its entirety. Many projects out there list multiple dependencies and may
have various building and distribution policies. The converse is to
believe that working around a problem in Phobos would render the DIP
less useful in general.
(2) "I don't like the syntax, hence I don't like the feature." I see
this as a good opportunity for tasteful design, not a downside of the
feature.
Maybe there are other issues having to do with symbol resolution and
dependency encapsulation that are addressed by this DIP, ie the
technical performance of the compiler rather than refactoring or code
clarity, that I don't fully grasp, but from the first two points of the
claimed benefits of DCDs, ie ease of reasoning about dependencies and
refactoring code, I don't think this feature will come anywhere close to
carrying its own weight.
Does the refactoring in https://github.com/dlang/phobos/pull/4962 make
dependencies clearer? Are you e.g. clear on what you need in order to
use Appender? Would you want to take this (or another) experiment to
another module and see how it improves its dependency structure?
As for the third benefit having to do with scalable template libraries,
I'm not sure I completely understand all the details there, but I wonder
if those problems aren't an artifact of the way dmd works now rather
than something that can't be fixed without this DIP.
The DIP now dedicates an entire section to the pluses and minuses of
lazy imports, and concludes that lazy imports would address scalability
if carefully used.
Andrei
