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

[Andrei Alexandrescu]

On 06/09/2010 02:34 PM, Michel Fortin wrote:
> On 2010-06-09 11:37:38 -0400, Don <nospam at nospam.com> said:
>
>> 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.
>>>
>>> Andrei
>>
>> On the other hand, I don't think we want a 5Mb module, either. There's
>> a very large number of potential containers, once you include all the
>> esoteric ones.
>
> Beside the size of the module, there is also the issue of namespace
> pollution. If you import std.container and you end up with a dozen of
> different containers plus their related functions, it's quite a lot. (Of
> course you can use selective import, but that's a workaround, it's
> better not have the problem in the first place.)

Say you import std.container and you end up with two dozen containers: 
Array, SList, DList, BinaryHeap (groovy baby!), RedBlackTree, Trie, ...

Where are the clashes?

>> (std.algorithm has the same problem, of course).
>> It's a difficult tradeoff. I hope you're able to come up with a
>> reasonable rationale.
>
> Personally I'd draw the line like this: a module should contain
> functions and types which are either tied in their implementation or
> which their use are correlated (if you use this thing you'll likely need
> this other one).
>
> For instance, a tree set and a tree map are almost the same, so they're
> good candidates to put together in a module (std.tree?).

Hm. On the other hand, if one is using a tree set that doesn't increase 
by a lot the likelihood of using a tree map.

> A linked list
> and an array are totally independent in implementation, and the need for
> one doesn't correlate with the need for another, so there's no reason to
> put them in the same module; they thus belong to separate modules.
>
> This "correlation in usage" rule should reduce the number of modules you
> need to import while also minimizing the number of symbols, the code
> size, and the dependencies of each module. What do you think?

I think we should look for a better rule.


Andrei