Does D have too many features?

[David Nadlinger]

On Monday, 30 April 2012 at 01:08:28 UTC, Jonathan M Davis wrote:
> On Sunday, April 29, 2012 17:50:48 Don wrote:
>> * package. I have no idea how a failed Java experiment got 
>> incorporated
>> into D.
>
> Really? In some cases, it's indispensable. For instance, once 
> std.datetime has
> been split up, it will require it, or it would have duplicate a 
> bunch of
> implementation-specific stuff which has no business in the 
> public API.

But what happens if std.datetime grows so large that you want to 
have e.g. a std.datetime.system package, the content of which is 
accessible from std.datetime.*, but not the rest of the world?

This is not an artificial problem, e.g. consider Thrift, where I 
have e.g. thrift.internal.endian (predating endian stuff in 
Phobos) which is used from modules in thrift.async, 
thrift.server, and thrift.protocol, or thrift.internal.socket 
(containing some more OS abstractions than std.socket does), 
which is used from modules in thrift.async, thrift.server, and 
thrift.transport, but both are not part of the public API.

The logical »package« to restrict access to would be 
»thrift.*« here, but there is no way to restrict access to 
that, I have to resort to hoping users understand that they 
should not use »thrift.internal.xyz« directly. Phobos has the 
same problem with std.internal.

I think in Java this problem was the reason for »super 
packages« to be discussed which (I think, haven't followed it 
the developments closely) ended up being incorporated in the 
upcoming Module System feature.

David