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

[Michel Fortin]

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.)


> (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?). 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?

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/