On Thu, Dec 19, 2013 at 01:47:26AM +0400, Dmitry Olshansky wrote: > 19-Dec-2013 01:40, Andrei Alexandrescu пишет: > >On 12/18/13 1:16 PM, Dmitry Olshansky wrote: > >>19-Dec-2013 01:06, Andrei Alexandrescu пишет: > >>>http://chopapp.com/#fvepfd8 shows the number of dependencies (plus > >>>1) for each module in phobos. Those include druntime dependencies. > >>> > >> > >>So the bill of using pretty much anything in Phobos is pulling in 87 > >>modules. Pretty much what I feared it is. > > > >There are several directions we can take this. > > > >1. Improve the compiler to handle imports lazily, i.e. an unused > >import is never opened. That's unlikely to help a lot of uses because > >most unqualified name lookups require all imports to be loaded (even > >after the name if resolved, the compiler must still look for > >ambiguities). > > > >2. Push imports from top level into the entities (functions, classes > >etc) that use them. > > > >3. Apply classic dependency management (break larger modules in > >smaller ones, accept some code duplication etc). > > > >I favor (2).
I vote for (2) as well. And for the first part of (3): I think std.algorithm is due for a breakup. There is no reason why using find, for example, should pull in sorting algorithms, and why using sorting algorithms should pull in cartesianProduct. > I'd add something that might help make (2) possible in case of > templates. > > 4. Split modules at least into a package of with at least 2 parts: > - Meta (traits) - constraints, type definitions etc. > - API - functions, globals and other "meat" of the module. > > One prime example is std.range - isInputRange, isForwardRange etc. > need not to be "bought together" with all of range adapters and > std.algorithm dependency. [...] I've been saying this over and over: now we have package.d, let's make use of it. Jonathan has been working on splitting up std.datetime (though that has yet to materialize); I think std.algorithm and std.range are due, too. T -- "Hi." "'Lo."
