Denis Koroskin: > I also quite don't understand why Phobos doesn't take advantage of > hierarchical modules structure. For example, I/O is a large cathegory and a > lot of elements belongs to it. Console I/O is just one of example, but there > is also network I/O, DMA etc. I believe it is much better to put each > independent element in its own module (to reduce intermodular dependencies > etc). For example, I put each class in a separate module. I believe it makes > analyzing source code *a lot* easier.<
I agree that std.io is better than std.stdio and I agree that a *bit* more hierarchical structure in Phobos can be good (but we have to avoid the silly deep nesting of Java libs), like adding one (1) more nesting level (only where it's actually useful and using the current flat structure anywhere possible): std.foo.bar.functionname Regarding putting one class into a single module, D isn't Java (and Phobos isn't Tango either), D allows you to group related public classes in to a single module. This helps reading source code and reduces the number of files to juggle around. Like nested functions, grouping more related functions/classes/templates into a single module gives you one more way to group things in a meaningful way. When you import it's generally better to qualify imports anyway, helping you to know where each name comes from: from std.foo: bar, Baz. Bye, bearophile
