Expanding Phobos from a flat hierachy

[Jonathan M Davis]

On Wednesday, February 06, 2013 08:56:26 Don wrote:
> In the "Implementing Half Floats in D" thread, we seemed to have
> reached a consensus on two important points:
> (a) Phobos should have a broad scope (rather than being small
> like the C standard library).
> (b) The current flat structure of Phobos (every module in the
> root) does not scale to hundreds of modules.
> 
> It's not quite unanimous on (a), but seems to be close enough.
> 
> Together, (a) and (b) mean we need a plan. The sooner we can do
> it, the less painful it will be. But, on the other hand, it's
> something that we really don't want to get wrong.
> 
> Personal taste plays a huge role in this (Practically any
> structure can work, but we're looking for an arrangement which is
> intuitive and aesthetically pleasing to as many people as
> possible). It'll be most productive to stick to uncontroversial
> facts as long as possible.

I agree that we should look at minimizing how many top-level modules we add in 
the future, but I don't think that it's generally worth trying to rearrange 
the modules that we already have. So, adding std.halffloat would be bad, but I'm 
not sure that it's worth doing something like moving std.uri into std.net. 
Even if we did, we'd be forced to leave std.uri around for quite some time (if 
not permanently, given Walter's attitude about such things), which negates the 
gain to some exent. You can also argue endlessly about what should be where in 
the hierarchy, which is needless bikeshedding. So, if we do any moving, we 
need to be sure that that's what we want to do and be done with it, and we 
shouldn't be moving new modules around. They need to go into the right spot 
when they're added, not be rearranged later.

> It would be great if people with extensive experience in other
> languages could give a brief description of the structure of the
> corresponding libraries. (Also include pseudo-standard libraries,
> for example boost in C++).

Java and C# would probably be good places to look, but I haven't dealt with 
either of them recently. It's easy enough to look at the docs though. They're 
well-organized. However, it should be kept in mind that both of those 
languages have the downside of being forced to have one public class per file 
(at least Java does - I don't remember for sure if that's true for C# or not), 
which can be good but is often overkill, which means that we wouldn't 
necessarily want to lay stuff out in quite the same way as they do, even if we 
agreed that they do a good job of it.

- Jonathan M Davis