On 06/09/2010 02:48 PM, Walter Bright wrote:
Andrei Alexandrescu wrote:
On 06/09/2010 07:57 AM, Michel Fortin wrote:
On 2010-06-08 17:41:22 -0400, "Simen kjaeraas" <[email protected]>
said:
Now, my favorite way of dealing with this: Where would I look for a
binary heap if I wanted one? I would think of it as a container, and
thus
check std.container. If it was not there, I would use the search
function
to find it. I can invent reasons, but it's mostly grounded in learned
names and categories.
And if you were accustomed to the STL, you'd just look for a binary heap
header to include instead of trying to philosophize about which category
of things it fits best. That's why I suggested "std.binaryheap" earlier.
(Could be "std.binheap" if you want it short.)
I don't think this will scale. There are quite a few data structures
out there, I'm afraid we'll have too many modules too soon.
One solution is to have std.container consist of the following:
public import std.containers.binaryheap;
public import std.containers.redblacktree;
I wanted to do that but with the singular:
public import std.container.binaryheap;
So if someone imports std.container then they get them all, if someone
imports std.container.something then they only get something.
Having a module and a package with the same name does not currently
work, and I don't think there's a good rationale for that limitation.
Andrei
