I don't see export as nonsense. :)
"Jonathan M Davis" wrote in message
news:[email protected]...
On Monday, April 30, 2012 06:58:18 David Nadlinger wrote:
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.
I'm not claiming that package solves all such issues (and you do give some
good examples where it would be a problem), but not having it would make the
problem even worse. I think that this is one area though where the Windows
folks take advantage of their export nonsense and just don't export the
internal stuff.
- Jonathan M Davis
