On 06/09/2010 02:34 PM, Michel Fortin wrote:
On 2010-06-09 11:37:38 -0400, Don <nos...@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.kja...@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
