On Wednesday, 24 June 2015 at 04:00:11 UTC, Andrei Alexandrescu
wrote:
std.allocator.allocator.IAllocator
std.allocator.allocator.theAllocator;
Yep, "ridiculous" is the first thing that comes to mind.
I find it difficult to digest (ehm) the fact that the same
community that thinks "std.allocator" is just not going to cut
the mustard, simultaneously believes "std.allocator.allocator"
is a good idea.
Of course you are right. It was indeed a poor suggestion. But
it's the only example I could find where a separate module name
was used to declare the high-level API. Perhaps it was even
written before package.d existed.
The case against std.allocator isn't about the name, but about
the fact that it doesn't do what people, apparently, expect:
import the entire public API.
I count only 4 uses of package.d in official Phobos:
https://github.com/D-Programming-Language/phobos/blob/master/std/algorithm/package.d
https://github.com/D-Programming-Language/phobos/blob/master/std/container/package.d
https://github.com/D-Programming-Language/phobos/blob/master/std/range/package.d
https://github.com/D-Programming-Language/phobos/blob/master/std/regex/package.d
All of them seem to import the entire public API, but only
std.algorithm.package.d is exclusively used for public imports.
The others all have some definition of high-level API features.
So, I don't see a precedent one way or another. And maybe that's
how it should be: defined based on the intended use of the
package.
Unfortunately, those against using package.d for the high-level
API, did not seem to offer a suggestion for where to put your
porcelain. So, if you wish to accommodate them and need a name,
consider std.allocator.api.
Mike
