Andrei Alexandrescu <[email protected]> wrote:
On 06/08/2010 10:53 AM, Simen kjaeraas wrote:
Andrei Alexandrescu <[email protected]> wrote:
But where should I put it then? I thought it would be even more
confusing if I put something in std.container that wait a minute, is
not a container.
How is it not a container? Because it uses a different container as a
back-end?
It does not implement the container primitives and is not a reference
type.
So it is not a container because you chose not to make it a container.
There are already rules that disambiguate range operations from similar
container operations. For example a range defines popFront() whereas a
container defines removeFront().
And my point is that removeFront() is popFront() with a different name,
so many containers could be considered ranges with mutated member
functions. :p But we're arguing semantics.
I agree that a BinaryHeap built on top of a container may ultimately
affect the topology of the container, which makes it unlike e.g. Take or
Chain. I could choose to disallow that and simply require that
BinaryHeap always works on top of a range, not a container. But I think
it's useful to have the growing functionality, and I don't think that
makes BinaryHeap hopelessly confusing.
To me, this makes it a container.
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.
--
Simen
