BinaryHeap is a range so it goes in std.range. Agree?

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Wed Jun 9 12:59:13 PDT 2010


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" <simen.kjaras at gmail.com>
>>> 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


More information about the Digitalmars-d mailing list