On 2010-06-09 15:44:48 -0400, Andrei Alexandrescu
<[email protected]> 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
[email protected]
http://michelf.com/
