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
