Does D have too many features?

Jonathan M Davis jmdavisProg at gmx.com
Sun Apr 29 22:05:59 PDT 2012


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


More information about the Digitalmars-d mailing list