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
