On Tuesday, 23 June 2015 at 15:56:15 UTC, Andrei Alexandrescu
wrote:
On 6/23/15 2:18 AM, Dicebot wrote:
On Monday, 22 June 2015 at 22:38:19 UTC, Andrei Alexandrescu
wrote:
Perhaps I misunderstood the request - currently the imports in
allocator/package.d are:
public import std.experimental.allocator.common,
std.experimental.allocator.typed; import std.algorithm,
std.conv,
std.exception, std.range, std.traits, std.typecons,
std.typetuple;
version(unittest) import std.random, std.stdio;
Is that okay, and if not what should change?
My concern was about the fact that symbols `IAllocator`,
`theAllocator`, `processAllocator` and bunch of others are
defined
within `package.d` itself and not provided via public import.
That
means that anyone willing to change default allocator or use
`make`
MUST import all std.allocator modules even if nothing else is
really
needed (those utilities look very independent). Which means
processing bunch of unnecessary imports - and more of those if
more
modules will get added to the package.
I'd prefer to have a small dedicated module, i.e.
`std.allocator.api`
(not going to discuss names!) and do public import of it from
`std.allocator.package.d`. Makes sense?
I see. Well this raises the question whether importing std.xyz
automatically means everything under std.xyz is transitorily
imported. Right now it's not - the more advanced/obscure
building blocks are not automatically imported if you just
import std.allocator; for those you'd need to import the
std.allocator.building_blocks package, or individual modules
from it like std.allocator.building_blocks.region.
This idea was proposed by Mike on 2015/05/18:
Would it be better to move the porcelain code into package.d
so the
nomenclature simply becomes `import std.allocator;`?
I liked the idea that someone who's not an expert goes "let me
import std.allocator and call it a day" whereas someone who
wants to tweak, customize, etc. they'd need to be more specific.
If we define an entry point such as "std.allocator.api",
novices will have one more thing to remember, or some will
still import "std.allocator" thus pulling everything without
realizing it.
So I'd say let's keep simple things simple. If you want to
allocate, import std.allocator.
Andrei
I agree with Adam on this: "Just a quick concern, I don't think a
package.d should ever have anything except imports in it"
(see
http://forum.dlang.org/post/[email protected])
for convenience the package.d could still import a bunch of
default stuff publicly for the "normal" user.
