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

[Michel Fortin]

On 2010-06-09 15:44:48 -0400, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> On 06/09/2010 02:34 PM, Michel Fortin wrote:
>> 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?

None... until you import something else that has a different Array 
type. If you import std.container because you need only BinaryHeap and 
doing this creates a clash with your own Array type you're going to 
have to disambiguate manually everywhere, rename your Array type 
everywhere, or to use a selective import. Not having the clash is 
better. And that clash will be quite frustrating if you need only 
BinaryHeap which has nothing to do with std.containers.Array.


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

Indeed, but since both share the same tree implementation, it'd be 
wasteful to make another module just for a few lines of code wrapping 
the same tree structure. The idea is to avoid creating a separate 
module for every small tweak of a core structure. There are multiple 
criteria which can be considered, my rule is based on two.


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

The rule I proposed was really "correlation in usage *or* shared 
implementation"; any of the two allows things to belong to the same 
module. The correlation avoids unnecessary imports, and the shared 
implementation part is to avoid scattering things in too many modules, 
and also to make it easier to keep common implementation details 
private.

But it's just a guideline, it's what I'd try to do, not necessarily 
what I'd do every time. You don't have to follow a guideline when it 
makes more sense to do something else.


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