On 6/23/15 6:07 PM, Andrei Alexandrescu wrote:
On 6/23/15 2:12 PM, Dicebot wrote:
So you have chosen worst of both worlds - neither give power users
ability to fine tune imports nor allow casual users always go with
`import std.allocator` and be happy? :)
There is functionality in std.allocator to get anyone started who
doesn't want to sit down and define their own allocator.
People who want to do that can import std.allocator.building_blocks
which is a package fully including all that's needed.
If anything, that will be the first package.d in Phobos (AFAIK) which
won't feature public import of _all_ package modules.
I'm not afraid of creating precedent if that's the best way to go.
Again: I have the impression we're blocked into an assumption we didn't
take critically until now.
What happened basically was:
1. There's too much crap in some modules, it's hard to maintain, hard to
process.
2. Let's split it up! Oh, but some people want to be able to import
everything a la java's import java.io.*, and existing code!!!
3. package.d is the solution, just import that and it's the same thing!
I personally think that if we want to define package.d as "importing all
the submodules", then we should stick to that. If we want to go another
direction, we need to redo all the other splitting of modules we have
done so far, as that is the pattern.
I'd recommend std.allocator.basic instead of std.allocator for a basic
direction. If it doesn't make sense to import ALL of std.allocator ever,
then drop package.d.
But you don't have to listen to me :)
-Steve
