On 06/09/2010 10:37 AM, Don wrote:
Andrei Alexandrescu wrote:
On 06/09/2010 07:57 AM, Michel Fortin wrote:
On 2010-06-08 17:41:22 -0400, "Simen kjaeraas" <[email protected]>
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.
(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.
I'm not sure what's the best approach. Best I can think of is by
category, e.g. all sequences go in std.sequence, all trees go in
std.tree, all hashes go in std.hash and so on. Since heaps are trees
they may be in std.tree. But then there are quite a few heap kinds out
there (binary, Fibonacci, binomial, soft) so perhaps std.heap is deserved.
Andrei
