phobos dependencies

Justin Whear justin at economicmodeling.com
Wed Dec 18 16:15:12 PST 2013


On Thu, 19 Dec 2013 00:51:04 +0100, Meta wrote:

> On Wednesday, 18 December 2013 at 23:08:21 UTC, Walter Bright wrote:
>> I favor (2), and also (4):
>>
>> 4. Break kitchen sink modules like std.algorithm into one module per
>> algorithm. This should not result in code duplication.
> 
> That seems a little over the top. While I guess it's not necessarily a
> bad thing to increase modularity, users would have to pull in a large
> number of imports to do anything nontrivial. For example, when you want
> to use sort, find, splitter and swap all together, you either have the
> choice of doing:
> 
> import std.algorithm;
> 
> And pull in everything, or doing:
> 
> import std.algorithm.sort, std.algorithm.find, std.algorithm.splitter,
> std.algorithm.swap;
> 
> Or is there something I'm missing here?
> 
> Of course, another large boon would be to correct the implementation of:
> 
> import std.algorithm: sort, find, splitter, swap;
> 
> So that it actually works in a sane way as opposed to pulling in
> everything.

Presumably there would still be a std.algorithm package module;  the 
questions is: does
  import std.algorithm : joiner;
still work if std.algorithm is actually a package module and joiner is in 
a std.algorithm.joiner module?


More information about the Digitalmars-d mailing list